pola negri
11.04.10,21:27
Nepoznate niekoho, kto sa vyzna trocha v programovaní a ovláda problematiku e-shopov a platieb kartami? Ak áno, uvitam kontakt, môžete aj cez SS.

Skusim popísať problém, aby ste boli viac v obraze. Ideme zriadiť e-shop s medzinárodnou pôsobnosťou. Ide o to, že popri bežnom predaji chceme ponúkať predaj vzoriek za výrazne zvýhodnenú cenu. Pointa je ale v tom, ze musíme zabezpečiť, aby bolo možné takto (so zľavou) nakúpiť iba 1ks z každého produktu na osobu.

Ja viem, že jesvujú rôzne cookies a pod, ze sa to dá spraviť tak, že sa človek k určitej funkcii po druhý raz nedostane z rovnakého počítača. Ale to sa mi nezdá vhodné. Na jednej strane to bude blokovať ostatných, ktorí by chceli ísť napr. z nejakého školského PC, na druhej strane sa to dá šikovnými užívateľmi určite nejako obchádzať, navyše každý ma aj NB...

Chcela by som to tak, aby bola rozhodujúcim kritériom poštová adresa. Teda, že by (bez ohľadu na meno) nebolo možné nechať si poslať tovar opakovane na rovnakú ulicu, číslo a mesto.

Už sme sa zmierili stým, že asi nebudeme mať program, ktorý by to v reálnom čase strážil. Sme ochotní to robiť my, manuálne, každého odkontrolovať porovnaním v databáze. Ale problém je v tom, ako mu umožníme zaplatiť kartou potom, čo jeho identitu a nákup schválime.

Teda - chcelo by to asi, aby sme mu poslali nejaký link, na stránku, kde by mohol kartou zaplatiť. No ten link by mal byť asi generovaný nejakým programom, a mal by byť použiteľný iba raz. Alebo nejaké heslo, aby sa dostal k tej platbe, bez hesla by sa nemal dostat. Dá sa to vôbec riešiť?

Díky moc.
sthruska
12.04.10,04:58
//Sme ochotní to robiť my, manuálne, každého odkontrolovať porovnaním v databáze.
To je nezmysel. Práve to je správna úloha pre databázu. Riešení je viac. Všetko to záleží od základného návrhu DB.
TomasHC
12.04.10,05:09
//Sme ochotní to robiť my, manuálne, každého odkontrolovať porovnaním v databáze.
To je nezmysel. Práve to je správna úloha pre databázu. Riešení je viac. Všetko to záleží od základného návrhu DB.

Tu ide o jedinecnu identifikaciu uzivatela, nie o navrh DB. Jedinecnost treba osetrit kodom, nie databazou.

Vsetko je otazka ceny/zisku. Kvoli par EUR sa neoplati kodit takze riesenia. Ak je to ale financne zaujimave, riesil by som to unikatnymi kodmi, a previazanim s adresou bydliska alebo bankovym uctom, cislom karty - nieco co sa neda na pockanie sfalsovat.
pola negri
12.04.10,05:16
//Sme ochotní to robiť my, manuálne, každého odkontrolovať porovnaním v databáze.
To je nezmysel. Práve to je správna úloha pre databázu. Riešení je viac. Všetko to záleží od základného návrhu DB.

No ideálne by bolo, ak by to mohla robit databáza automaticky. Lenže program asi nikdy nebude tak inteligentný ako človek. Predpokladám, že by bolo ľahké ho oklamať, adresa sa dá napísať mnohými rôznymi spôsobmi, napr. v nemčine Parkstrasse, ale aj Parkstr., alebo Parkstraße. Predpokladám, že program by mal problém, ak by zadal niekto niečo raz s diakritikou, na druhy raz bez, alebo by pridal medzeru a pod.

Jedine spoľahlivé automatické riešenie by som si vedela predstaviť, ak by sa spravila kompletná databáza adries na celom svete a potom by človek iba rozklikával a vyberal z ponúk, napr. Štát (vybehol by zoznam krajín) - voľba: Slovakia, ďalej by vybehol zoznam miest a obcí (ako napr. zoznam letísk, ked si človek kupuje letenku) - volba napr. Bratislava, potom by musel vybehnúť zoznam ulíc v Bratislave a užívateľ by vybral voľbu. Toto je ale samozrejme nereálne.

Ale toto sa ešte dá riesiť tým manuálnym porovnávaním, aj keď to bude prácne. Ale s čim si nevieme poradit, ako takému (preverenému) človeku umožniť zaplatiť kartou.
pola negri
12.04.10,05:27
Tu ide o jedinecnu identifikaciu uzivatela, nie o navrh DB. Jedinecnost treba osetrit kodom, nie databazou.

Vsetko je otazka ceny/zisku. Kvoli par EUR sa neoplati kodit takze riesenia. Ak je to ale financne zaujimave, riesil by som to unikatnymi kodmi, a previazanim s adresou bydliska alebo bankovym uctom, cislom karty - nieco co sa neda na pockanie sfalsovat.

Pokiaľ viem, platba kartou prebieha tak, že obchodník sa k žiadnym údajom na karte nedostane. Zákazník je jednoducho z e-shopu presmerovaný na stránku banky (spolu s informáciou, koľko má platiť), až tam zadá číslo karty a zaplatí, banka potom posiela info o platbe obchodníkovi.

Ak som už písala, viem, že sa to robí tak, že sa identifikuje PC, napr. pri hlasovaní v rôznych anketách. Ale takýto spôsob ochrany pre nás nie je veľmi vhodný. Preto sme to ochotní robiť hoci aj manuálne, no pokiaľ zákzníkovi neumožníme automatický prístup na tú stránku banky, kde má platiť (pretože ho treba najprv preveriť), musíme mu to nejako umožniť po preverení. A práve v tom je problém.
Fero11
12.04.10,06:09
Niesom programator, ale mozno trochu analizujem.
Osetril by som to tak. Kazdy kto chce nakupovat sa musi najprv zaregistrovat, vyplni vstupne udaje (pravdive, na ktore mu bude zasielany tovar)
Tym padom bude zapisany do DB pod jedinecnym ID
A uz mas o nom prehlad, co kedy kupoval a kolko.
Ak kupi produkt, ktory ty povolis, aby mohol kupit iba raz, tak ak ho bude chciet kupit znova, jednoducho mu to uz nepojde (resp. pojde az po urcitom case, aky sa nastavi)
Nieje tam ziadny vpliv s akeho PC sa pripaja, cookies, IP adresy atd ...
Jednoducho vsetko je to o databaze a povoleniach
Duchanito
12.04.10,12:18
ak by si mala prechadzat kazdy zaznam rucne .. uf ...

zalezi podla DB... ak pouzivate DB, ktora podporuje stored procky tak by som su urobil napr taku ktora pri registracii noveho zakazika (po vlozeni zaznamu do tabulky) okontroluje ci sa tam uz cloviecik s rovnakou adresou nenachadza. Ak ano oznaci zaznam (bude tam vytvoreny napr. pomocny atrib) alebo odosle email poverenej osobe s idckom noveho zakaznika s podozrenim na duplicitu. a osoba sa uz bude venovat len moznym duplicitam, cize len naozaj zlomok prace. A uz bude na nom rozhodnut ci ide napr o osobu s rovnakou adresou (otec, syn, mamka, babka atd.) alebo naozaj pokus klamat.
pola negri
24.04.10,10:31
ak by si mala prechadzat kazdy zaznam rucne .. uf ...

zalezi podla DB... ak pouzivate DB, ktora podporuje stored procky tak by som su urobil napr taku ktora pri registracii noveho zakazika (po vlozeni zaznamu do tabulky) okontroluje ci sa tam uz cloviecik s rovnakou adresou nenachadza. Ak ano oznaci zaznam (bude tam vytvoreny napr. pomocny atrib) alebo odosle email poverenej osobe s idckom noveho zakaznika s podozrenim na duplicitu. a osoba sa uz bude venovat len moznym duplicitam, cize len naozaj zlomok prace. A uz bude na nom rozhodnut ci ide napr o osobu s rovnakou adresou (otec, syn, mamka, babka atd.) alebo naozaj pokus klamat.

No fajn, ale aj tak nam to nereisi problem - ako umoznit platbu kartou niekomu, kto bude napr, odmietnuty pre podozrenie na duplicitu, ale koho my manualne schvalime. Ako ho presmerovat na tu stranku banky spolu (s informaciou, kolko ma platit) tak, aby ten link fungoval iba jednorazovo (a nedalo sa pomocou neho platiti nabuduce).
Flinstone
24.04.10,10:59
No fajn, ale aj tak nam to nereisi problem - ako umoznit platbu kartou niekomu, kto bude napr, odmietnuty pre podozrenie na duplicitu, ale koho my manualne schvalime. Ako ho presmerovat na tu stranku banky spolu (s informaciou, kolko ma platit) tak, aby ten link fungoval iba jednorazovo (a nedalo sa pomocou neho platiti nabuduce).
jedine tak, že registrácia nového zákazníka nebude automaticky... napr. zákazník sa zaregistruje, nahádže si košík, ale objednať si bude môcť až po potvrdení registrácie adminom. A tam je možnosť kontroly. Už po objednaní by všetko malo prebiehať automaticky včítane platby.
Fero11
24.04.10,12:50
No fajn, ale aj tak nam to nereisi problem - ako umoznit platbu kartou niekomu, kto bude napr, odmietnuty pre podozrenie na duplicitu, ale koho my manualne schvalime. Ako ho presmerovat na tu stranku banky spolu (s informaciou, kolko ma platit) tak, aby ten link fungoval iba jednorazovo (a nedalo sa pomocou neho platiti nabuduce).
Ty uz v databaze musis urcit, ze konkretny user nema moznost viac si kupit pozadovany tovar (iny tovar ano).