[php] links niet meer aanklikbaar

[Verwijderd]

hoi,

Ik heb een zoekmachine ontwikkeld met PHP die een database doorzoekt en de zoekresultaten weergeeft.

Het probleem zit hem in de resultatenpagina.
Dit is een aparte pagina (PHP) die wordt gegenereerd adhv de ingevulde zoektermen.

Op de resultatenpagina worden steeds 10 resultaten getoond en men zou moet kunnen bladeren door op een link te klikken.

De query dient aan de link meegegeven te worden en dit doe ik encrypted.

Dit werkte allemaal prima: de query moet worden meegegeven omdat de query voor de zoekactie per zoekactie verschilt. Hij wordt dynamisch samengesteld door mijn script.

De link komt er als volgt uit te zien:

zoekresultaten.php?offset=8&limit=8&qid=MA8zHzkfOUswTGABNiBmZjZuNj00WTAgY2U1MDM0Mi1qb2IBO2w6ZDVubngycG5gYmM0T2ZyN2tkfmk3PGFiITAoMyI5JzlKMG5gITZ1Zmg2KjYiNHEwIWNUNSgzLzI%2FamZiKjsoOnE1ZG44MlRubmJuNGZmczdxZGFpPDwhYnswJDMuOQM5YjBuYDQ2dGZ2NiY2NzR6MHVjczUkMykyDmprYj87ZTpxNXVueDJwbnpiezRUZnU3dmR0aSA8ZmJlMC8zdjknOXYwe2AFNnJmbDZsNiU0JTAhY381KDMNMixqbmI0O3c6cTVpbjEycm4uYns0f2ZzN0tkaWkzPGhiajBtM3Y5Jzl2MHtgHDZtZmQ2YTYzNDsweWNzNSQzKTIXampiPztjOmA1NW54MnBuemJ7NE5majdjZGNpNzw7YiMwKDMiOSc5QTBiYCY2Y2ZtNnQ2PzRjMCNjbjUyMzoycmpzYiY7cDpWNXJuNTJwbndifDQrZm43b2RjaR48YGJoMDMzdjk%2FOWAwaGAKNkhmcDZvNiU0QDARYys1KDMlMipqVGIqO2U6cTVzbicyKG52Ym00a2ZMN25kZWk8PHtiajAyM3Q5Jzl2MHtgGzZhZmQ2azZ2NGgwJmMnNTEzPDI1amJiMjtlOmQ1dG54MmhubGJoNFhmRDduZG1pNzxhYnswFTMeOX85ejB3YCE2VGZ8NnY2MzQpMHVjJzV8M30yfmonYn47JDolNSZudDIkbghiLzQnZic3ImQkaXI8L2IvMHwzejlzOS4wL2ATNlJmSjZLNnY0fTA3Y2s1DDMxMj9qZmIqO3c6YDVobngycG5gYmM0T2ZyN2tkfmk3PGFiIzAoMzg5PzlaMHZgJTZlZik2cjY0NGUwHmNrNT0zMzIqamJiMDskOiU1Jm5eMiRuImIvNCdmJzciZCRpcjwvYi8wfDN6OXM5WTBHYBA2UmZANiY2fjR9MDdjazUMMzEyP2pmYio7dzpgNWhuejJobmxiaDRXZms3Y2RlaSY8fGJGMBgzZzknOWwwY2AdNnVmbDZ8NjM0ZzB7Y2s1MjM6Mg5qa2I%2FO2U6cTV1bh0yQG4rYi80RmZJN0ZkJGlYPAZiBjB8M3o5czkuMC9gdTYgZiU2JjZ2NCkwfWNzNT4zMTIWanJiNzt%2BOmA1aG56MmhubGJoNEpmZjdpZGFpPjxuYm4wLjMTORc5MzB7YDc2bGZONmo2NzRnMCFjYjUyM3MyMmppYjk7WzpGNWpuPTJhbmxiezROZkM3K2QkaRM8QWJLMHwzUzlaOS4wL2B1NiBmJTYmNnY0KTBfYw41VTN9Mn5qJ2J%2BOyQ6JTUmbnQyJG4iYi80L2ZzN2BkaGkaPHpiZjAmMz85PTkgMGNgOzZnZlE2fzYmNGwwHGNDNWEzKTI8amtiCjt9OnU1Y256MmhubGJoNFNmfjdyZGFpGzxLYiYwfDMbOR05SjAvYF82CWYMNiY2djQpMHVjJzV8M30yfmonYn47JDotNXJuNjJoblJiYzRmZmY3dmR3aTc8YWIhMDAzNDk0OUswa2A8NnRmbDZjNh80TTB1Y2s1NTM2MjtqJ2J5OyE6IDUhbn0yJG4iYk40SWZDNyJkLGkmPG1iYzAMMzY5MjlvMHtgJjZlZms2KDY6NGcwMmNXNTAzPDI%2FanNiLTtNOkE1O25lMjVuM2IvNEhmVTciZHBpMDxjYl8wMDM7OTI5ejB8YDA2bmYrNmo2ODRuMAVjazU9MzwyKmp0Yhc7QDo4NTduZDI1biJiQDRVZic3dmRmaT48X2JjMD0zOzknOX0wamA7Ni5maTZoNjE0WTA5Y2Y1PTMpMi1qTmIaOzk6NDUzbmYyLW4iYk40SWZDNyJkLGl6PHtidzAoMwo5ITlnMGVgJjY%2BZjg2NjZ2NEgwG2NDNXwzKTImanNiDjt2Omw1bG4nMjhuP2I2ND5mPjc7ZD1pazwmYi8wEzMIOXM5ejB3YCE2UGZ3Nm8

[Yep, dit ziet eruit als crap en dat is precies de bedoeling]

Maar als ik op de link wil klikken om naar de volgende reeks resultaten te gaan, kan ik er niet op klikken!
Heeft iemand enig idee hoe dit kan?

Ik zat zelf te denken aan het feit, dat de URL misschien te lang geworden is?!

[whoami]

Dat zou kunnen.
Een URL mag eigenlijk maar 255 karakters zijn.

[elnino]

Op donderdag 11 juli 2002 12:40 schreef FourEyes het volgende:
Ik zat zelf te denken aan het feit, dat de URL misschien te lang geworden is?!

Gebruik je <A HREF="http://blaat/">Blaat</A> om een link te maken? Oftewel: toon wat uitvoer.

Overigens mag een URL maximaal 1024 tekens ¹⁾ hebben, dacht ik. Ik heb het aantal tekens hier niet geteld, maar het zijn er wel behoorlijk wat. Controleer dat ook nog even.

Succes!

¹⁾ edit: Was het maximum nou 1024 of 255? Ik weet het niet precies. Ik heb even wat gezocht, maar ik lees op de ene site wat anders dan op een andere site. Nu weet ik het ook niet meer...

Ik heb nog even verder gezocht en het verschilt per browser. Ik quote Thargol even uit [topic=333077]:

Op dinsdag 27 november 2001 20:40 schreef Thargol het volgende:
Die 255 is afhankelijk van de browser die je gebruikt. In IE4.0 en hoger is het namelijk 2048 karakters. Zie ook http://support.microsoft.com/support/kb/articles/Q208/4/27.ASP

In dat Microsoft-artikel staat:

INFO: Maximum URL Length Is 2,083 Characters in Internet Explorer (Q208427)
Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters, with a maximum path length of 2,048 characters. This limit applies to both POST and GET request URLs.

If you are using the GET method, you are limited to a maximum of 2,048 characters (minus the number of characters in the actual path, of course).

POST, however, is not limited by the size of the URL for submitting name/value pairs, because they are transferred in the header and not the URL.

RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 , does not specify any requirement for URL length.

Het verschilt dus per browser, veel oudere browsers ondersteunen maximaal 255 tekens.

[Stewie!]

encrypte ze dan wat korter. Wat heeft het nu voor nut dat je zoveel tekens daar hebt staan?

[drm]

volgens mij is de max 255 characters.

Je zou het evt. met een post op kunnen lossen, maar imo is zo'n url uberhaupt een beetje overdreven...

[Verwijderd]

Ik gebruikte een standaard encryption script wat ik ook gebruik voor loginmodules etc. Dit script versleuteld het met 3 "zinnen" en MD5 er bovenop.

Ik dacht dat ik hetzelfde script wel kon gebruiken.

[drm]

Maar waarom zou je een zoekopdracht willen versleutelen?

[Verwijderd]

http://www.w3.org/Protocols/rfc2068/rfc2068

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs.

Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths.

Dus ik verwacht niet echt dat de lengte van de URL het probleem zou zijn. Overigens, waarom moet die URL zo onmogelijk lang zijn? Met md5 hou je toch hooguit 16 karakters over en voor je toepassing hoef je vast niet meer dan 1 zo'n "checksum" te hebben?

Bovendien als je dit voor een of andere beveiliging gebruikt, dan trek ik mijn twijfels aan de effectiviteit. Er zijn vast veel betere (lees: kortere, makkelijkere, veiligere) methoden beschikbaar. Als je aan encryptie denkt, bijvoorbeeld HTTPS. Of meer aan geldigheid van de waarden, sessies.

[Stewie!]

wat ik nu niet snap, je doet een md5 erover heen, maar je kan een md5 toch niet meer terugdraaien? Die is toch niet te decoden, of wel soms?

[Verwijderd]

Als mensen een query zien in een URL dan is de uitnodiging groot en verleidelijk wellicht om eens wat met die veldnamen van de tabel te gaan doen (updates, insert etc.) en das bij een belangrijke site niet de bedoeling natuurlijk.

De encryptionclass die ik gebruik werkt erg goed vind ikzelf en is uitermate geschikt voor encryptie van passwords in databases.

Passwords zullen zelden langer zijn dan 10-20 karakters en de encrypted versie blijft dan ook kort.

Ik wil de class best posten als jullie interesse hebben ...
Ik gebruik hem heel vaak en je kunt de encryptevoorwaarden (regels om te versleutelen) zelf aanpassen.

[Rashann]

Op donderdag 11 juli 2002 14:55 schreef FourEyes het volgende:
Als mensen een query zien in een URL dan is de uitnodiging groot en verleidelijk wellicht om eens wat met die veldnamen van de tabel te gaan doen (updates, insert etc.) en das bij een belangrijke site niet de bedoeling natuurlijk.

Door naar de broncode van de pagina met het FORM te kijken kan je ook achter die veldnamen komen... dus zo extra veilig is het niet.

Misschien moet je toch maar eens een andere encoder proberen die de te encoden tekst niet (al te veel) verlengt... hoeveel velden zijn er eigenlijk te encoden? en hoe lang is een gemiddelde URL zonder encryptie?

[Verwijderd]

Die is toch niet te decoden, of wel soms?

Het is onmogelijk om met zekerheid het origineel weer terug te krijgen, tenzij je kan aantonen dat bij de gegeven hash-code maar 1 origineel kan zijn dat past bij eventuele kennis dat je van het origineel hebt. Maar dan zou het geen goede hashfunctie zijn, want een hashfunctie dient juist zo goed mogelijk invoer over het domein te spreiden. Dus ga er maar niet vanuit dat bovenstaande geldt.

Waar je het dus wel voor kan gebruiken is als "checksum", omdat men bij md5 er vanuit gaat dat het wat tijd betreft ondoenlijk is om een vervangend origineel te vinden met dezelfde key (vooral als dit ook nog aan bepaalde voorwaarden moet voldoen).

Maar waarvoor zo'n checksum in dit geval nodig is...?
[edit] ... is in de tussentijds gepost

[Janoz]

Nou, dat vind ik een oplossing als "Ohw, we missen de putdeksel, latten we er snel een muur omheen metselen zodat niemand erin valt"

Door gewoon de meegegeven variabelen te controleren ipv te encrypten zijn dit soort dingen veel makkelijker af te vangen.

[Verwijderd]

Voor je zoekopdracht hoef je toch maar enkele variablen op te geven:

- zoekstring
- offset
- aantal resultaten op 1 pagina

Bij elke aanroep van je script doe je iets met die zoekstring en genereer je de query.
Vervolgens beeld je met de overige twee variable de juiste records af.

Een query opstellen aan de hand van een zoekstring, zodanig dat de essensie van de query niet door de bezoeker kan worden gewijzigd (ofwel, dat niet met je tabellen gekloot kan worden) is heel eenvoudig.

Waar is die beveiliging dan voor nodig?

[Verwijderd]

Tsja, dat kun je vinden, maar voor passwords werkt ie wel perfect.

En trouwens:
aan de hand van de veldnamen van het formulier kun jij achterhalen wat de database-veldnamen zijn?! Dat vind ik pas ontzettend knap.

Ik weet namelijk niet als ik ik een veld "a" noem, dat dat dan bijvoorbeeld een woningtype of een autotype is. Vreemd dat jij dat wel kan.

Maar als jij een query ziet staan in een URL wordt het al een stuk makkelijker. Vandaar dat ik het wilde en encrypten, zodat de bezoeker een nietszeggende URL zou zien. Maar dit bleek dus niet de juiste oplossing.

Iedere keer de veldnamen meesturen en de querie dynamisch opstellen kost teveel performance / tijd etc. daarom wilde ik de querie meesturen. Het encrypten hoeft namelijk maar eenmalig en het decrypten gaat 15x zo snel als het opstellen van de query (heb ik gebenchmarked).

[Rashann]

Op donderdag 11 juli 2002 15:12 schreef FourEyes het volgende:
Tsja, dat kun je vinden, maar voor passwords werkt ie wel perfect.

En trouwens:
aan de hand van de veldnamen van het formulier kun jij achterhalen wat de database-veldnamen zijn?! Dat vind ik pas ontzettend knap.

Ik weet namelijk niet als ik ik een veld "a" noem, dat dat dan bijvoorbeeld een woningtype of een autotype is. Vreemd dat jij dat wel kan.

Maar als jij een query ziet staan in een URL wordt het al een stuk makkelijker. Vandaar dat ik het wilde en encrypten, zodat de bezoeker een nietszeggende URL zou zien. Maar dit bleek dus niet de juiste oplossing.

Iedere keer de veldnamen meesturen en de querie dynamisch opstellen kost teveel performance / tijd etc. daarom wilde ik de querie meesturen. Het encrypten hoeft namelijk maar eenmalig en het decrypten gaat 15x zo snel als het opstellen van de query (heb ik gebenchmarked).

Ah, ik had je dus verkeerd begrepen...
tja, dan wordt het dus zaak om of goed te checken (zie post Janoz) of een andere, kortere, encryptie te gebruiken.

En je zou natuurlijk ook in plaats van links allemaal FORMpjes kunnen gebruiken maar dan wordt je pagina wel groot en is de query via de source nog wel te zien.

[Verwijderd]

psies!

Nu plaats ik de encrypte query voorlopig maar even in een koekje

[Dennis]

Ik ben het helemaal met Janoz eens, dit is echt een walgelijke oplossing.

Je kan zoals gezegd ook gewoon op iedere pagina die query opnieuw opbouwen, het zal heus niet zo zijn dat dat eeuwen duurt (en indien dat wel zo is mag je de code hier plaatsen en dan zullen we je databasemodel eens doorspreken ).

[dusty]

Op donderdag 11 juli 2002 15:12 schreef FourEyes het volgende:
[..]
Maar als jij een query ziet staan in een URL wordt het al een stuk makkelijker. Vandaar dat ik het wilde en encrypten, zodat de bezoeker een nietszeggende URL zou zien. Maar dit bleek dus niet de juiste oplossing.
[..]

Query in de URL (of cookies) is gewoon dom, Maakt niet uit of het gecodeerd is of niet. Query's ga je nooit aan de client geven, waardoor je um terug krijgt bij de volgende pagina en dus op de "CLIENT" moet vertrouwen dat het inderdaad niet "gekraakt" is.

[Infinitive]

Waarom stuur je veldnamen mee met je URL? Dat is vast niet nodig.

Iedere keer de veldnamen meesturen en de querie dynamisch opstellen kost teveel performance / tijd etc. daarom wilde ik de querie meesturen. Het encrypten hoeft namelijk maar eenmalig en het decrypten gaat 15x zo snel als het opstellen van de query (heb ik gebenchmarked).

Ik weet niet wat je gebenchmarkt hebt, maar ga er maar van uit dat het opstellen e.d. in vergelijking met de rest van het werk (bijvoorbeeld het uitvoeren van de query om maar wat te noemen) helemaal in het niet valt.

Bovendien, als het encrypted/decrypted sneller is, wel, dan heb ik niet zoveel vertrouwen in je encryptie methode...

[Verwijderd]

als je dan toch wilt voorkomen dat mensen met je querystring gaan focken... kun je altijd een frameset waarvan de bovenste frame 0 of 1 pixels is en dus leeg is.
de onderste frame komt dan je content in. in deze pagina zet je dan ook een script (javascript ofzo) dat ervoor zorgt dat je 'main' ALTIJD in binnen die frameset zit.

verder (zoals al gezegd) ...NOOIT sql-queries of cookievars in de querystring plaatsen anders kun je net zo goed meteen je serverwachtwoorden en code posten.

Greetz

may the code be with ya

[Verwijderd]

Ok thanks jongens ...

Ik ben het onderhand helemaal eens met jullie, dat het een achterlijke oplossing is ... Ik ga er flink over nadenken in ieder geval

Zo kom je steeds dichterbij een goede oplossing.

[mees]

is het niet een idee om er een form van te maken? dan staan er helemaal geen vars meer in de url...

ik dacht aan iets als:

PHP:

<?echo "<form name=volgende method=POST ACTION=bestandsnaam.php>";echo "<input type=hidden name=string value=".$string.">";echo "<input type=hidden name=nogwat value=".$verdereinfo.">";echo "</form>";echo "<a href=\"javascript:void();\" onclick=\"javascript:document.volgende.submit;\">";?>

(weet niet meer of dat de juiste javascript-link was, maar zoiets dus..)

(en natuurlijk meerdere hidden inputs mogelijk)

[peter99]

Je kan toch in je url de zoekwaarden doorgeven en het resultaat nummer?

daarna een query met WHERE zoekveld Like '%$zoekwaarde%' LIMIT $resultaat_nummer,10