[PHP/(My)SQL] voor dummies - Deel 35

quote:

Op woensdag 27 december 2006 07:22 schreef mschol het volgende:

[..]

als ik start-> uitvoeren->cmd
telnet 10.0.0.180 3306
doe dan krijg ik het versie nummer van mysql terug en wat garbage
kan alleen niet inloggen omdat hij een handsake wil hebben

Ik doelde meer op mysql -h hostname.com -u user -p vanaf je client naar je server.

Mmm. ik zie dat je de user ELKE wilt laten inloggen, met passwd, maar die heeft er geen. Denk dat daar je probleem ook zit.
-edit: dat gaf je ook aan, ik ben ook nog niet wakker-

quote:

Op woensdag 27 december 2006 08:54 schreef Tuvai.net het volgende:

[..]

Nogmaals, zoals Swetsenegger eerder al aangaf, waarom zo omslachtig en moeilijk liggen doen wanneer een captcha een effectieve én eenvoudige oplossing is? Sowieso zou ik Javascript echt niet gaan gebruiken wanneer het niet echt nodig is, maar goed, dat is gewoon hoe ik in het algemeen over Javascript denk.

Sowieso zou je oplossing niet werken daar je gewoon met een <input> werkt, of die nou hidden is of niet. Dan zou het gewoon voor het spambot 'formuliertje' een kwestie zijn om deze input zelf in te stellen.

een captcha is hinderlijk voor de user. hidden geeft als voordeel dat de user er totaal geen last van heeft. en de spambot zou zijn formulier dan met een exacte waarde moeten aanpassen op jouw site. en met een ander scriptje kan je dan weer dagelijks die waarde laten veranderen waardoor een succesvolle spambot dagelijks geupdate moet worden om het te kunnen omzeilen.

ik vind het een methode, en ik zie momenteel niet in hoe het niet zou kunnen werken. tenzij je geen javascript hebt ingeschakeld, maar das debiel.

ik vind ze hinderlijk.

helemaal als ze slecht leesbaar zijn en ook nog eens hoofdlettergevoelig.

quote:

Op woensdag 27 december 2006 22:51 schreef Swetsenegger het volgende:

[..]

Slecht leesbaar is om die OCR bots op het verkeerde been te zetten, maar ik ben met je eens dat die captcha's die je 3 keer in moet tikken omdat je het blijkbaar verkeerd ontcijferd had langzamerhand het doel voorbij schieten.

niet langzamerhand, zodra je em 1x mis kan tikken schiet het z'n doel voorbij imho...

quote:

Op woensdag 27 december 2006 23:28 schreef Swetsenegger het volgende:

[..]

Dat langzamerhand slaat op spamcontrol in het algemeen.

Feit is wel dat spamcontrol nodig is. Anders blijf je berichten aan het verwijderen.

quote:

Op donderdag 28 december 2006 01:19 schreef Swetsenegger het volgende:

[..]

Vertel mij wat. zelfs op mijn fucking weblogje waar geen hond naar keek.
Ik heb 50K records moeten wissen...

Ongeveer net als mijn weblogje dus. In een voorzichtige schatting komt nog steeds op bijna 95% van de reacties op spam uit.

quote:

Op woensdag 27 december 2006 20:50 schreef Desdinova het volgende:

[..]

een captcha is hinderlijk voor de user.

Het is voor mij veel 'hinderlijker' om elke dag duizenden spamberichtjes te verwijderen dan even 5 nummertjes/lettertjes over te tikken als ik toch al in het betreffende formuliertje bezig ben, effe tabben en overtikken dus.

quote:

Op donderdag 28 december 2006 15:17 schreef Tuvai.net het volgende:

[..]

Het is voor mij veel 'hinderlijker' om elke dag duizenden spamberichtjes te verwijderen dan even 5 nummertjes/lettertjes over te tikken als ik toch al in het betreffende formuliertje bezig ben, effe tabben en overtikken dus.

Jij bent geen gewone gebruiker. Je bent webmaster en hebt begrip voor die captcha's. De "gewone" gebruiker ervaart dit anders.

quote:

Op donderdag 28 december 2006 19:34 schreef beerten het volgende:

[..]

Jij bent geen gewone gebruiker. Je bent webmaster en hebt begrip voor die captcha's. De "gewone" gebruiker ervaart dit anders.

Doet er niet toe. Ik zie gewoon niet de 'hinder' in het overtikken van een paar karakters die ergens afgebeeld staan. Wel vind ik dat je als webmaster een linkje er bij moet zetten waar uitleg staat waarom ze die code over moeten tikken.

De meest simpele en effectieve methode die voor mij werkt is gewoon elke post waar in 1 van de velden "http://" staat te weigeren. Spammers willen immers URL's plaatsen, anders hebben ze niks aan het gespam. Ik pas dit op verschillende plekken toe, en heb totaal geen last meer van spambots

quote:

Op donderdag 28 december 2006 21:15 schreef Bartje71 het volgende:
De meest simpele en effectieve methode die voor mij werkt is gewoon elke post waar in 1 van de velden "http://" staat te weigeren. Spammers willen immers URL's plaatsen, anders hebben ze niks aan het gespam. Ik pas dit op verschillende plekken toe, en heb totaal geen last meer van spambots

En wat als ik, als doodnormale gebruiker, in jouw gastenboekje wil posten "Hoi Bart, gave site! Check die van mij ook eens op http://www.site.com!".

Dat is inderdaad een keuze. Maar op de meeste sites wil ik gewoon geen URL's om spam tegen te gaan... niet van bots en niet van mensen die hun site proberen te pluggen.

quote:

Op donderdag 28 december 2006 21:36 schreef Bartje71 het volgende:
Dat is inderdaad een keuze. Maar op de meeste sites wil ik gewoon geen URL's om spam tegen te gaan... niet van bots en niet van mensen die hun site proberen te pluggen.

Sta je een url überhaupt niet toe? Of laat je de link achterwege? Dus geen <a href=""></a>?

@beerten: ik denk dat hij urls gewoon helemaal niet toestaat

Ik heb zelf geen last van het probleem omdat ik geen anonieme dingen toelaat op mijn site(s).
Als ik dat wel zou hebben zou mijn oplossing zijn om via css een veld (met logische naam) een paar honderd duizend pixels naast het venster te zetten en wanneer er toch iets in dat veld is ingevoerdgewoon de post te blocken

Ik sta inderdaad helemaal geen URL's (en ook geen html) toe. Maar het hangt een beetje van je toepassing af of dat bruikbaar is.

quote:

Op vrijdag 29 december 2006 00:41 schreef joolee het volgende:
@beerten: ik denk dat hij urls gewoon helemaal niet toestaat

Ik heb zelf geen last van het probleem omdat ik geen anonieme dingen toelaat op mijn site(s).
Als ik dat wel zou hebben zou mijn oplossing zijn om via css een veld (met logische naam) een paar honderd duizend pixels naast het venster te zetten en wanneer er toch iets in dat veld is ingevoerdgewoon de post te blocken

dan zou je ook kunnen zeggen dat je hem met css gewoon een display: none geeft

maar je zou toch ook een session kunnen aanmaken op het formfield, of een cookie, wat je vervolgens weer kan checken op de post-pagina? of heeft dat haken en ogen?

Ik krijg de laatste paar dagen ineens weer (pogingen tot) spam in mijn gastenboekjes. Ik gebruik zelf een captcha waarvan de code in een soort van handschrift-font word weergeven en waarvan de startwaarde z'n x en y assen random zijn. Ik krijg dan vaak één spamberichtje wat dan gewoon door mijn captcha heenkomt, vervolgens krijg ik de dagen/uren daarna op gastenboek.php een hoop GET en POST requests met spam, maar met diezelfde captcha code die natuurlijk dan niet goed meer is.

Misschien een echte persoon die 't altijd eerst effe uitprobeert?

Mensen,

Hoe werkt een webshop eingelijk? want voor mijn vriendin ben ik er reeds 1tje aan het maken maar kwam vandaag tot de ontdekking dat het toch best een heel karwei is!

Nu wil ik graag hoe een webshop het doet na de bestelling, want produkten in een database is niet echt heel moeilijk te realiseren (heb ik al) maar hoe gaat het na het moment dat de klant de produkten besteld!? wat voor manieren hebben jullie gebruikt en wat raden jullie mij aan?

Zelf heb ik nu uitgedokterd dat de produkten (in dit geval is er maar is er voor ieder produkt maar 1) gewoon op 0 in het systeem (database) komen te staan. En dan verbind ik een code aan al deze artikelen dmv een link tabel (id, code, klant_id, produkt_id) er kunnen dus ook meerdere produkten met dezelfde code in de database staan.

Hoe lossen jullie dit op?

Elk product sowieso een uniek ID geven in de producten-tabel van de database, en een 'aantal' veldje per product.

Meeste van m'n klanten willen dat de webshops die ik voor hun bouw zo werken, dat wanneer iemand iets besteld, ze dat kunnen zien in een aparte 'Bestellingen' pagina in het Admin Panel. Voor bestellingen dus ook een aparte tabel in de database. Vaak willen ze dat dan gecombineerd met een mail systeempje zodat ze naderhand de totaalprijs plus de bijbehorende portokosten kunnen mailen door enkel deze bedragen in te voeren. Je kunt natuurlijk ook nog andere betaalmogelijkheden er aan vast hangen zoals Paypal en iDeal.

Vaak werk ik overigens ook met het 3 stappenplan:
1) Email validatie. Klant plaatst bestelling en vult daarbij natuurlijk z'n gegevens in. Er word vervolgens een mail gestuurd naar het ingevulde adres met een linkje waar de klant zijn email adres kan verifiëren.
2) Betalingsvalidatie. Klant moet natuurlijk betalen. Wanneer de eigenaar/webmaster dit bedrag ontvangen heeft, gaan we naar stapje 3.
3) Verzenden van product.

Correct, natuurlijk heeft ieder produkt zijn eigen ID, echter heeft deze webshop van ieder artikel maar 1 stuk...

Ik heb nu 2 tabellen.

1. klanten (gegevens van de klant)
2. klanten_bestellingen (link naar produkten + code van de bestelling)

doe jij het ook zo?


^{best pittig hoor, een webshop bouwen}

Ik heb meestal een tabel 'bestellingen'. Pas wanneer de klant de bestelling doet gaat er een record naar deze tabel waar de bestelling en de gegevens van de klant in staan. Een aparte tabel voor klanten heb ik alleen bij de webshops waar klanten bijvoorbeeld een vast account kunnen registreren.