Moi olen aikeissa opetella koodaamaan. Ensimmäisenä trendikkäänä projektina olen tutkinut ostoskorien sekä lomakkeiden luomista. Jokainen tutkimani verkkokauppalomakkeen lähetys on tehty PHP:llä. Enkä pidemmän tutkinnan jälkeen ole hahmottanut varsinaista syytä. Omia epäilyksiä kylläkin.
Alkuperäinen tavoite on pysyä irti kaikenmaailman tietokannoista joka käsittääkseni ei ole ongelma html:llä ja js:llä. Ja tässä selvittelenkin onko tavoitteeni todella naiivi.
Kysyisinkin mitkä ovat isoimmat sudenkuopat jos luon html+js apuna käyttäen ostoskorin josta ohjautuu maksusivulle? Ja siitä eteenpäin maksusivulta lomakkeen täytön kera aina maksutapahtumaan ja sivuille paluu. Siinä kysymys lyhykäisyydessään, mutta valotan hieman lisää raameja varoiksi jotta tavoitteeni valottuisi hieman paremmin. Maksusivulle siirtyy toki ostosvalinnat ja maksusivulla on lomake (+ captcha tms) jolle annan parametrejä jolla lomakkeen täyttö menee uusiksi jos ne eivät täyty. Ja jos parametriarvot täyttyvät lähtee submitilla kauppa maksuun sekä tiedot lomakkeilta muutamaan sähköpostiin. Ja maksutapahtumasta kiitossivulle josta lähtee jälleen sähköpostia. Tässä onkin isoin kysymys mitkä ovat edut ja heikkoudet jos tämän toteuttaa html+javascript? Mietin ovatko koodaajat tapojensa orjia, vai onko siihen useita painavia syitä miksi tiedonsiirtoon liittyvät koodipätkät tuntuu kallistuvan php koodiin?
Mielelläni kuulisin myös näkemyksiä html+js vs. php turvallisuus näköpuolelta? Noobierookien maalaisjärjellä verkkokaupan ja maksupalvelutarjoajan väliin on hankala päästä, siten että rahat jäisi tielle tietymättömälle (kun käyttää suomalaista maksupalveluntarjoajaa). Isoimmaksi ongelmaksi näkisin että henkilötiedot lomakkeesta siirtyisivätkin väärään osoitteeseen (kun itselleni on välttämätöntä saada ne). Onko enemmän tai vähemmän jotain mitä en ole osannut hahmottaa? Ja jos on niin kuinka vakavasti ne on otettava pienemmillä ja hiljaisemmillakin sivuilla joilla mahdollisesti raha saattaa hieman liikkua?
Näissä asioissa kielellä ei ole vaikutusta turvallisuuteen. Jos olet nähnyt vain php:llä toteutettuja lomakkeenkäsittelijöitä, niin sitten olet luultavasti etsinyt ainoastaan php:llä toteutettuja lomakkeenkäsittelijöitä; ei php sentään niin dominoiva kieli web-kehityksessä ole.
Javascriptkin toimii erinomaisesti, kunhan nyt ymmärrät että puhuvasi palvelimen päässä ajettavasta koodista, etkä oleta, että pelkästään käyttäjän selaimessa ajettavalla sovelluksella voisi tehdä mitään tuollaista. Vähintään palvelinpuolella täytyy tallentaa tilaus ja varmistaa maksusuorituksen onnistuminen.
Suoratmutkiks kirjoitti:
Alkuperäinen tavoite on pysyä irti kaikenmaailman tietokannoista joka käsittääkseni ei ole ongelma html:llä ja js:llä. Ja tässä selvittelenkin onko tavoitteeni todella naiivi.
Ja miten ajattelit pysyä erossa tietokannoista? Todellinen nettikauppa tarvitsee tietenkin sekä tuotetietokannan (listan saatavilla olevista tuotteista hintoineen) että tilaustietokannan (lista tilauksista, asiakkaiden nimet ja osoitteet, jne.).
Jos aiot vain koemielessä tehdä sivun, joka näyttää verkkokaupalta, niin siitä vaan. Jos taas haluat harjoitella todellisen toimivan sivun, tarvitset tietokantoja.
Kuten The Alchemist totesi, kieli on sivuseikka mutta suorituspaikka tärkeä. Oletankin, että ”HTML+javascript” tekstissäsi tarkoittaa oikeasti ”selaimessa suoritettava koodi” ja vastaavasti ”PHP” tarkoittaa ”palvelimella suoritettava koodi”. Käytä jatkossa tällaisia termejä, jotta vältytään epäselvyydeltä.
Suoratmutkiks kirjoitti:
Kysyisinkin mitkä ovat isoimmat sudenkuopat jos luon html+js apuna käyttäen ostoskorin josta ohjautuu maksusivulle?
Olennaista on ymmärtää, että kaikki käyttäjälle lähetettävä (yleensä siis kaikki HTML ja JS) on julkista tietoa. Käyttäjä voi lukea kaiken tämän tiedon, joten mitään salaisuuksia ei saa tässä koodissa tai datassa olla. Omalla kohdallaan käyttäjä voi myös vapaasti manipuloida saamaansa tietoa. Jos sivulla lukee ”123,99 €", käyttäjä voi tähän itse kirjoittaa tilalle ”0,99 €”. Jos sivulla lukee ”maksu epäonnistui”, käyttäjä voi tähän itse kirjoittaa ”maksu onnistui”.
Verkkomaksussa on pakko olla myös palvelimella suoritettavaa koodia: Ennen maksua täytyy tarkistaa tilauksen sisältö ja hinta. (Yleensä kannattaa jo tässä vaiheessa tallentaa tilaus jonnekin siltä varalta, että maksutapahtuma keskeytyy ja tilausta joudutaan selvittelemään asiakkaan kanssa.) Maksun jälkeen täytyy tarkistaa maksun onnistuminen ja merkitä tämä tieto johonkin sellaiseen paikkaan tai sellaisessa muodossa, että asiakkaalla ei ole mahdollisuutta huijata. Jos vain lähetät sähköpostiisi viestin ”Pete on maksanut”, mistä tiedät, ettei asiakas ole lähettänyt viestiä sinulle huijauksena itse? (Ok, kyllä sen voi yleensä aavistaa, mutta parempi tehdä kunnolla.)
Suoratmutkiks kirjoitti:
Alkuperäinen tavoite on pysyä irti kaikenmaailman tietokannoista
Jos et aio käyttää tietokantaa, mihin sitten aiot tallentaa tiedon? Yleensä verkkokaupan täytyy jossain säilyttää mm. tuoteluetteloa, varastosaldoa ja tilauksia. Sähköposti on aika surkea väline tilausten hallintaan, jos niitä oikeasti tulee suurempi määrä.
Tietenkin tilanne on yksinkertaisempi, jos et ole tekemässä verkkokauppaa vaan sähköpostivälitteistä tilauslomaketta parille vakiotuotteelle pienelle asiakaskunnalle.
Hyviä vastauksia. Hahmotin monta asiaa kiitos :) Kuten hyvin alkeellisen mutta tärkeän pointin ettei kaupassa ilmeisesti tuote tallennu ilman palvelinta. Loogista mutta kurjaa. Jotenka "maalaisjärkeilin" kiertotien.
Selvennän vielä hieman lisää jotta ymmärrätte paremmin alempana kertomani kiertotien. Yleisen koodauksen opiskelun lisäksi on tarkoitus myös myydä tekstitiedostoja. "Samoista" tekstitiedostoista yksikään ei ole täysin identtisiä toistensa kanssa jotta ne ovat jäljitettävissä. Koska eri tiedostojen myyminen saman artikkelin alta verkkokaupassa olisi ikävä vaikeuasteen nostaminen koko projektille, olen päättänyt luopua siitä. Samalla saavutetaan myös turvallisuusetuna se että yksikään tiedosto ei lähde instana. Vaan ne lähetetään manuaalisesti heti ( tai hieman myöhemmin ) kun on saatu vahvistus ostotapahtumasta. Tämän takia on kohtalaisen sama saanko viestin että olen saanut 123,99€ maksun sijaan 0,99€ maksun. Aikomuksena on maksun toteutuminen täysimääräisenä tarkistaa maksupalveluntarjoajalta ennen tuotteen lähetystä. Ja maalaisjärkeilylläni oletan sen toteutumisen näkyvän instana (korjatkaa jos olen väärässä) maksupalveluntarjoajalla. Ehkä tärkein ilmoitus on että saan viestin sähköpostiin toteutuneen maksutapahtuman kiitossivulta (todennäköisesti tämä on toteutettavissa myös maksupalveluntarjoajalla että saan heiltä spostin jokaisesta toteutuneesta kaupasta) että tiedän kaupan tapahtuneen. Toki lomaketietojen saapuminen sähköpostiin myös tärkeä, mutta se ei vielä ole tae siitä että maksusuoritus on tapahtunut ja lomaketiedoilla olisi mitään merkitystä.
En tarvitse varastosaldoja tuotetietokantoihin, tilauksia villeimmissäkin unelmissani tulisi sen verran harvakseltaan että ne hoidetaan "instana" manuaalisesti eikä listoina. Tuotteita alkuunsa 1-2kpl, myöhemmin EHKÄ muutama lisää. Asiakkaiden nimet ja osoitteet voin ottaa ylös sähköpostista. Hahmoittelemani myyntitapahtumien määrä per viikko on 2-10kpl jotenka kirjanpidollisesti päälleni ei lankea kaaos. Ja jos tapahtumia alkaa olemaan enemmän voi olla taloudellisesti mahdollista palkata ammattikoodaaja siksi aikaa kunnes itse olen oppinut asioita tarpeeksi pitkälle :)
Periaatteessa voisin siis tehdä kiertotienä jopa alasivun per tuote jossa suoraan maksulomake sekä maksupalveluntarjoajan maksuvaihtoehdot ja submitilla suoraan maksutapahtumaan. Vai onko näin että en kykene verkkomaksuun kyseisessäkään skenaarioissa ilman palvelimella suoritettavaa koodia?
Toinen kiertotie joka tuli mieleen ja millä vältetään tilauksen hinnan ja sisällön tarkistus palvelimelta olisi luoda illuusio perinteisestä ostoskorista. Kahdella tuotteella olisi helppo luoda 3 eri kassaa joista verkkokauppa lataa omansa eri ostoskenaarion toteutuessa (0+0, A+0, B+0). Joista tietenkin neljäs skenaario jäisi pois koska se vaatisi maksujen jäämistä johonkin palvelimelle muistiin (A+B) jollei tee osta molemmat nappulaa. Tiedän että aikamoista puuhastelua, mutta tekee projektista minulle mahdollisen sekä parantaa visuaalista vaikutelmaa ostajalle verkkokaupasta.
Suoratmutkiks kirjoitti:
Yleisen koodauksen opiskelun lisäksi on tarkoitus myös myydä tekstitiedostoja. "Samoista" tekstitiedostoista yksikään ei ole täysin identtisiä toistensa kanssa jotta ne ovat jäljitettävissä. Koska eri tiedostojen myyminen saman artikkelin alta verkkokaupassa olisi ikävä vaikeuasteen nostaminen koko projektille, olen päättänyt luopua siitä.
En osaa edes kuvitella, mikä voisi olla helpompi tapa yksilöivän tunnisteen upottamiseen kuin tehdä se ohjelmallisesti.
Koko sinun sepustustasi vaivaa sellainen harhaluulo, että ohjelmointi on vaikeusasteella "erittäin vaikea" ja kaikki käsin turhanpäiväisesti säätäminen olisi samalla asteikolla tyyliin "melko helppo". Ehkä ohjelmointi ei ole sinun juttusi.
Kyllähän toki tilaussysteemi on mahdollista tehdä selainpään koodillakin jos maksujen tarkistaminen ja tilausten hallinnointi halutaan tehdä manuaalisesti. Silloin ei kuitenkaan voi puhua verkkokaupasta vaan ehkä juuri "tilaussysteemi" olisi kuvaavampi nimi :D
Ostoskori itsessään tuskin on se ongelma tuossa. Sen kun vain lisäät kamaa javascript -listaan, ja ostoskori näyttää ko.listan sisältöä. Tietenkin jos backendiä ei ole (eikä täten sessiota), tulee sinun tallentaa tiedot keksiin jotta pysyvät muistissa sivunlatausten välillä.
Mitä tulee ylläolevaan keskusteluun, Ei tuollaisen simppelin tilaussysteemin tekeminen backendiä käyttämällä ole kovinkaan haastava homma, varmasti löydät ohjeita ihan mille kielelle tahansa. Uskonkin että eteesi tulee haasteita pelkällä html + js combolla enemmän, kuin käyttämällä backendiä tukenasi (perusmallilla db jossa tuotteet ja niiden hinnat, session käyttö ostoskoria varten ja tilauksen lähetys sähköpostilla).
En jaksa lukea kaikkia viestejä, joten voi tulla jo jotain mihin on vastattukin.
Toteutus riippuu täysin siitä millainen kyseinen verkkokauppa on.
Sehän voi olla vaikka "käsin" copypastettu html-tuotelista, jossa ei ole erillistä "ostokoria", vaan tuotteet tilataan vain tuotteiden kohdalla olevilta mailto -linkeillä.
Tämmöisen tekemiseen ei tarvita ostoskoria tai tietokantoja, mutta kuten aina, ohjelmoinnilla saadaan tehtyä rutiineja joilla esim. tuotelistanäkymä saadaan järkevämmin rakennettua.
Voidaan siis miettiä mistä halutaan oikoa. Tuollainen hyvin yksinkertainen "verkkokauppa" voi soveltua hyvin pienille toimijoille, eikä vaadi ohjelmointia (vaikkakin semmoisenkin tekemiseen suosittelisin silti ohjelmointia) .
Lebe80 kirjoitti:
Voidaan siis miettiä mistä halutaan oikoa. Tuollainen hyvin yksinkertainen "verkkokauppa" voi soveltua hyvin pienille toimijoille, eikä vaadi ohjelmointia (vaikkakin semmoisenkin tekemiseen suosittelisin silti ohjelmointia) .
En usko sen soveltuvan yhtään kellekään vaikka monet voivat kyllä sopeutua rajoituksiin. Kunnolla toimivia verkkokauppa-alustoja on valmiiksi saatavilla monenlaisilla varusteluilla, joten mitään syytä huonon tekemiseen ei erikseen ole.
The Alchemist kirjoitti:
– –
Kyse ei ollutkaan tästä, vaan vastasin vain AP:n otsikkoon: "Onnistuuko verkkokauppa ilman PHP:tä (HTML+JS)?"
Lebe80 kirjoitti:
Kyse ei ollutkaan tästä, vaan vastasin vain AP:n otsikkoon: "Onnistuuko verkkokauppa ilman PHP:tä (HTML+JS)?"
Kyse mistä? Lainauksessa ei ole sisältöä, joten yhtä hyvin voisit jättää koko quoten pois.
Suoratmutkiks kirjoitti:
todennäköisesti tämä on toteutettavissa myös maksupalveluntarjoajalla että saan heiltä spostin jokaisesta toteutuneesta kaupasta
En tiedä, onko. Verkkomaksujen idea on, että tieto maksun onnistumisesta välittyy saman tien verkkokauppaan – myyjän palvelimelle. Rajapinnat on tätä ajatellen suunniteltu. Tämä on kaikkien kannalta paras tapa: asiakas saa heti tiedon, että tilaus on hyväksytty; myyjä saa heti tiedon, että maksu on onnistunut; maksupalvelussa on vain yksi rajapinta, joka sopii kaikille.
Voit itse koodata palvelimellesi sivun, joka tarkastaa maksun ja lähettää sinulle sähköpostia aiheesta. Voit saman tien koodata kunnollisen verkkokaupan. Katsoin Paytrailin integraatioesimerkkejä, ja ne näyttivät niin yksinkertaisilta ja helposti kopioitavilta, että sanoisin tämän maksupuolen olevan enintään pari prosenttia sivuston toteuttamisen vaivasta verrattuna kaikkeen muuhun (kuten ostoskoriin ja ulkoasuun).
The Alchemist kirjoitti:
Kyse mistä?
Varmaan siitä, onko syytä tehdä huonoa. AP ei kysynyt, onko syytä tehdä huono, vaan kysyi, voiko huonon tehdä. Jää meidän vastaajien tehtäväksi kysyä häneltä, onko hänellä syy tehdä huono.
The Alchemist kirjoitti:
Lainauksessa ei ole sisältöä, joten yhtä hyvin voisit jättää koko quoten pois.
Teknisesti se on varmaan minun syyni: Laitoin sivuston poistamaan turhat yhden kokonaisen viestin lainaukset. Ärsyttää sellainen """"""A"B"C"D"E"F"-ketju. Keskustelut venyvät ja lukeminen vaikeutuu, ja informaatiota ei synny kokonaisen viestin kopioinnissa yhtään lisää.
The Alchemist kirjoitti:
Lainauksessa ei ole sisältöä, joten yhtä hyvin voisit jättää koko quoten pois.
Näkeehän siitä ainakin _kenelle_ viesti on suunnattu. Tosiaan, lainauksen sisällön poistuminenhan ei ollut omaa syytäni, vaan putkaan on kyseinen ominaisuus tullut salakavalasti.
The Alchemist kirjoitti:
– –
Tähän pitää sanoa, että välillä lainaus jää pois vaikka se esikatselussa näkyisi Tähänkin on otettu lainaus sisään mutten tiedä näkyykö sitä ennen kuin sen lähetän. Meni aiheen ohi mutta tähän väliin hyvä sanoa. Jos vaikka korjattaisiin ;)
Ei näkynyt. Lainaukseen otettu seuraava viesti The Alchemist [26.10.2015 18:21:30]
Haa, ja vastaus ongelmaan lukeekin jo yläpuolellani.
Aihe on jo aika vanha, joten et voi enää vastata siihen.