[PHP/(My)SQL] voor dummies #106

quote:

Op maandag 28 januari 2013 23:50 schreef GlowMouse het volgende:
ik zeg ftp account gehackt; iemand heeft de ftp-gegevens op zijn pc opgeslagen en diegene heeft een virus

aha..gelukkig..of niet..maar dan ligt het niet aan mij, maar aan de admin
als het dat is...nu hopen dat er een recente backup ergens is
ben al aan het fixen geweest maar in al de js files staat ook een document rewrite

quote:

Op maandag 28 januari 2013 23:30 schreef MrNiles het volgende:
ineens heb ik in elk mapje op een site een default.php bestand,
hierin staat
<?php eval(gzinflate(base64_decode("een hele hoop karakters hier"))); ?>

site gehackt?
kreeg ook een redirect naar een of andere darwin...... .fr
ligt het aan mij...of kan het ook aan mijn hostingprovider liggen, dat die gehackt is.
Of is het totaal iets anders?

Haal die eval en gzinflate functie er eens omheen en maak het volgende er van:


Dit soort acties zijn ideaal om verdere uitbreiding van een script te realiseren. Heb er zelf ook al een keertje aangewerkt namelijk

quote:

Op dinsdag 29 januari 2013 00:00 schreef MrNiles het volgende:

[..]

aha..gelukkig..of niet..maar dan ligt het niet aan mij, maar aan de admin
als het dat is...nu hopen dat er een recente backup ergens is
ben al aan het fixen geweest maar in al de js files staat ook een document rewrite

quote:

Op dinsdag 29 januari 2013 00:00 schreef MrNiles het volgende:

[..]

aha..gelukkig..of niet..maar dan ligt het niet aan mij, maar aan de admin
als het dat is...nu hopen dat er een recente backup ergens is
ben al aan het fixen geweest maar in al de js files staat ook een document rewrite

Hoewel GlowMouse eigenlijk altijd gelijk heeft vind ik het een beetje kort door de bocht om te zeggen dat de ftp account gehacked is.

Dit kan net zo goed zijn gebeurd via bugs of security holes in the server software of de webapplicaties die geinstalleerd zijn.

Basic rule: zorg dat alles up to date is.

[ Bericht 0% gewijzigd door Darkomen op 29-01-2013 12:03:35 (dt fail) ]

'vind ik'

Als je het zeker wilt weten moet je contact opnemen met de hoster, want dit kan inderdaad ook door andere dingen komen. Die kan de logfiles napluizen waar jij niet bij kunt. Maar dat ftp accounts gehackt worden en zulke code toegevoegd, gebeurt al zeker 3 jaar.

quote:

Op dinsdag 29 januari 2013 08:55 schreef Pakspul het volgende:

[..]

Haal die eval en gzinflate functie er eens omheen en maak het volgende er van:
[ code verwijderd ]

Dit soort acties zijn ideaal om verdere uitbreiding van een script te realiseren. Heb er zelf ook al een keertje aangewerkt namelijk

Als je wil weten wat de code is die uitgevoerd wordt moet je natuurlijk de gzinflate functie wel laten staan, als je dat niet doet krijg je nog steeds een hoop garbage als output aangezien het is gecomprimeerd.

quote:

Op dinsdag 29 januari 2013 12:02 schreef GlowMouse het volgende:
'vind ik'

Als je het zeker wilt weten moet je contact opnemen met de hoster, want dit kan inderdaad ook door andere dingen komen. Die kan de logfiles napluizen waar jij niet bij kunt. Maar dat ftp accounts gehackt worden en zulke code toegevoegd, gebeurt al zeker 3 jaar.

Hoster denkt dat het Gumblar is.
Niet zo fijn als ik de verhalen op internet allemaal moet geloven

Heeft Glowmouse toch weer gelijk !

Glowmouse aka God.

Korte vraag,

Ik heb een internet kassa die het resultaat van een betaling automatisch dmv POST doorgeeft aan een door mij ingestelde URL. Daar heb ik een php script welke het resultaat verwerkt, zoals de order table updaten met het resultaat van de betaling, klant mailen met de gegevens van de bestelling, etc.

En daarbij wil ik ook direct de sessie van het winkelwagentje resetten, maar... dat lukt niet. Mijn $_SESSION['cart'] wordt niet geleegd.

Ik heb nu op die pagina $_SESSION naar een txt file gedumpt dmv de volgende code


Dit geeft als resultaat NULL. De sessie bestaat op desbetreffende pagina blijkbaar helemaal niet?

Gebruik ik namelijk dezelfde code op de pagina waar de internetkassa de gebruiker heen stuurt (manual response) krijg ik


Waarom heeft de automatic response pagina geen sessie informatie

-edit-
Opgelost, op de automatic response pagina had ik geen sessie id, want geen cookie info uiteraard. Nu sessie id in de url van de automatic response geparsed en daarmee de sessie op die pagina gestart.

[ Bericht 3% gewijzigd door Swetsenegger op 31-01-2013 16:38:56 ]

Ik hoop wel dat je die sessie op een of andere manier beveiligd hebt

Ander vraagje dan maar

Is er een algemene stelregel voor welke kolommen een index zouden moeten hebben? Bijvoorbeeld altijd op kolommen die je gebruikt in JOINS of iets dergelijks?

quote:

Op donderdag 31 januari 2013 17:06 schreef Chandler het volgende:
Ik hoop wel dat je die sessie op een of andere manier beveiligd hebt

Leg uit wat je bedoelt.

quote:

Op donderdag 31 januari 2013 17:10 schreef Swetsenegger het volgende:
Ander vraagje dan maar

Is er een algemene stelregel voor welke kolommen een index zouden moeten hebben? Bijvoorbeeld altijd op kolommen die je gebruikt in JOINS of iets dergelijks?

Het veld van de 'op tellende' waarde? en verder lijkt mij niet dat er een stelregel is oid... maar logisch gezien pak je de velden die voor je applicatie het meest belangrijke zijn (dus waarmee je zoekt). en de links tussen bepaalde velden die waarde hebben..

^{ben geen expert zoals glowmouse..}

quote:

Op donderdag 31 januari 2013 17:10 schreef Swetsenegger het volgende:
Leg uit wat je bedoelt.

Je roept een externe url aan met allerlei post gegevens, dan neem ik aan dat de connectie tussen beide systeem een bepaalde controle uitvoert?

quote:

Op donderdag 31 januari 2013 17:14 schreef Chandler het volgende:

[..]

Het veld van de 'op tellende' waarde? en verder lijkt mij niet dat er een stelregel is oid... maar logisch gezien pak je de velden die voor je applicatie het meest belangrijke zijn (dus waarmee je zoekt).

^{ben geen expert zoals glowmouse..}

[..]

Je roept een externe url aan met allerlei post gegevens, dan neem ik aan dat de connectie tussen beide systeem een bepaalde controle uitvoert?

Omnikassa van de rabobank. Je post allerlei gegevens zoals return url (nu dus met sessie info), totaalbedrag,merchant ID, etc etc en die wordt gehashed met een secret key.

Lijkt me voldoende toch? Of moet ik nog wat met die sessie ID voor de verbinding van kassa -> webshop?

Nee, lijkt mij voldoende, vroeg mij alleen op opzet even af.

quote:

Op donderdag 31 januari 2013 17:10 schreef Swetsenegger het volgende:
Is er een algemene stelregel voor welke kolommen een index zouden moeten hebben? Bijvoorbeeld altijd op kolommen die je gebruikt in JOINS of iets dergelijks?

Het hangt volledig van de queries uit, lees bv. het boek over High Performance MySQL over uitleg over indices.

quote:

Op donderdag 31 januari 2013 17:10 schreef Swetsenegger het volgende:
Is er een algemene stelregel voor welke kolommen een index zouden moeten hebben? Bijvoorbeeld altijd op kolommen die je gebruikt in JOINS of iets dergelijks?

Je kan in MySQL de slow query log aanzetten en configgen om te checken welke queries eventueel vertraging opleveren in je applicatie of laten aangeven welke queries geen gebruik maken van indexes.

Als je een website maakt voor een lokale bakkerij zou ik er geen tijd in steken en gewoon je auto increment een primary geven. Het kan leuk zijn voor een oefening, maar de tijdswinst is zo marginaal bij kleine low traffic sites dat het de moeite niet loont om complexe indexes op te zetten.

quote:

Op donderdag 31 januari 2013 17:18 schreef Swetsenegger het volgende:

[..]

Omnikassa van de rabobank. Je post allerlei gegevens zoals return url (nu dus met sessie info), totaalbedrag,merchant ID, etc etc en die wordt gehashed met een secret key.

Lijkt me voldoende toch? Of moet ik nog wat met die sessie ID voor de verbinding van kassa -> webshop?

Het meesturen van het sessie-ID naar de rabobank vind ik raar. De sessie is iets tussen jou en de bezoeker en daar heeft de rabobank niets mee te maken. Zodra de bezoeker terug komt op jouw website (door een redirect vanaf de rabobank) zou de browser van je bezoeker automatisch het sessie-cookie weer mee moeten sturen.

quote:

Op donderdag 31 januari 2013 19:48 schreef papernote het volgende:

[..]

Het meesturen van het sessie-ID naar de rabobank vind ik raar. De sessie is iets tussen jou en de bezoeker en daar heeft de rabobank niets mee te maken. Zodra de bezoeker terug komt op jouw website (door een redirect vanaf de rabobank) zou de browser van je bezoeker automatisch het sessie-cookie weer mee moeten sturen.

De rabobank heeft er ook niets mee te maken, maar de pagina die de bestelling verwerkt wel.
De kassa heeft 2 return url's. Een URL waar de klant komt als die in de kassa op "klaar" klikt (normalReturnUrl), en 1 waar altijd een response heen gePOST wordt (automaticResponsUrl).

Het probleem van de eerste is dat je nooit zeker kan weten DAT de klant terug komt en is dus onbetrouwbaar voor het updaten van je order. Dat doe je dus op de automaticResponseUrl.

Wil ik op DIE pagina ook bij een geslaagde betaling de sessie van de winkelwagen 'unsetten' moet ik het sessieid wel in de automaticResponseUrl meesturen.

Maar ik heb nu voor de zekerheid de sessieID maar ge-mcrypt_encrypt voor hij naar de kassa gaat en hij wordt gedecrypt in de automaticResponseUrl. Dat lijkt me meer dan veilig genoeg

quote:

Op donderdag 31 januari 2013 23:06 schreef mstx het volgende:
De winkelwagen kun je al legen op de pagina waar het formulier (die je doorstuurt naar omnikassa) opgebouwd wordt. Als het goed is is op dat moment je winkelwagen al omgezet naar een order en heb je die dus niet meer nodig.

Swets heeft wel gelijk want stel de betaling gaat niet goed, dan is het handig dat de winkelwagen nog gevuld is toch?

quote:

Op donderdag 31 januari 2013 23:06 schreef mstx het volgende:
De winkelwagen kun je al legen op de pagina waar het formulier (die je doorstuurt naar omnikassa) opgebouwd wordt. Als het goed is is op dat moment je winkelwagen al omgezet naar een order en heb je die dus niet meer nodig.

Ik heb nu dat wanneer de betaling niet gelukt is, de items nog in de winkelwagen staan. Kan de klant direct een nieuwe order insturen.

quote:

Op vrijdag 1 februari 2013 08:19 schreef mstx het volgende:

[..]

Nee. Dan heb je in je account een onbetaalde order staan met een betaalknopje om het nog een keer te proberen.
Maar goed, dat ligt natuurlijk ook aan hoe je systeem werkt maar dit vind ik de meest logische manier.

Eh ja, dan staat er dus 1 niet geactiveerde order en 1 wel geactiveerde order (als de 2e betaling lukt). Wat is precies het probleem? Zie ik wat over het hoofd?

quote:

Op vrijdag 1 februari 2013 08:35 schreef mstx het volgende:

[..]

"Probleem" is een groot woord, maar ik zou het fijner vinden als er in totaal maar 1 betaalde order bij mijn bestellingen staat als de betaling bij de 3e keer pas lukt, in plaats van 1 betaalde en 2 niet-betaalde.

Maar die niet betaalde toon ik uiteraard niet aan de klant, alleen de 'geactiveerde'.

Ik had inderdaad ook gewoon een 'mijn orders' pagina kunnen maken met een 'probeer opnieuw' knopje. Mijn ervaring is wel dat voor veel mensen webshops nog steeds 'eng' zijn en ze nog een keer door een bekende betaalstraat heen loodsen misschien sneller geprobeerd wordt.

Nou ja, het was een keuze. Achteraf met wat haken en ogen.