[java/php] encode / decode gegevens

[B-Man]

Ik ben al een tijdje op zoek naar een manier om gegevens in URLs te versleutelen op een gemakkelijke manier.

Ik genereer URLs in Java, de URLs verwijzen naar een php script dat de input in de URL zal werken.

Het gaat bijvoorbeeld om http://pad/test.php?id=1&action=run&account=5

Nu zie ik regelmatig ge-encode informatie in de volgende vorm:
{61F9C32E-FE5E-4745-AA83-230D5E34E0CD}
(zit ook in windows 2000)

Is dit een standaard algoritme? en zo ja, waar vind ik meer informatie over dit algoritme?

Waarom ik URLs wil versleutelen? (laat ik de vraag maar voorzijn )
De voorbeeld-URL die ik noem is "leesbaar" en kan uitnodigen tot wijziging door de gebruiker (power-user). Ik controleer natuurlijk op validiteit, enz, maar door de URL te encoden naar een formaat als hierboven ook genoemd wordt de drang een stuk kleiner lijkt me.

--

Oh, ik heb het over het encoden van de query_string, in bovenstaand voorbeeld dus "id=1&action=run&account=5".

[ Voor 10% gewijzigd door B-Man op 24-10-2003 16:22 ]

[Verwijderd]

Misschien is het verstandiger om een POST methode te gebruiken ipv een GET methode....

dan zijn je url's niet direct aanspreekbaar.

user session tracking kan je misschien beter doen met cokies

[Verwijderd]

POST is opzich een oplossing ja, maar dan heb je nog dat er bijv. een password ongecodeert over het netwerk vliegt... En dus kan iedereen met een sniffer je pass. zien...

Als iemand antwoord: svp ook voor JSP/EJB (struts)?

Sessiontracking mag niet via cookies (vindt ik)... sommige mensen kiezen ervoor geen cookies te gebruiken, dan zouden ze dus geen gebruik kunnen maken van je site...

Sessiontracking zou ik liever in de http-session willen zetten..

[ Voor 35% gewijzigd door Verwijderd op 24-10-2003 17:07 ]

[B-Man]

Ik heb het niet over session tracking...

Teven is mijn vraag niet of ik GET of POST beter kan gebruiken, hiervan ben ik op de hoogte. Mijn vraag gaat enkel over de methode waarmee de string in mijn openingspost is geencode.

[B-Man]

Verwijderd schreef op 24 October 2003 @ 17:06:
POST is opzich een oplossing ja, maar dan heb je nog dat er bijv. een password ongecodeert over het netwerk vliegt... En dus kan iedereen met een sniffer je pass. zien...

offtopic:
SSL bij login is ontworpen voor dit soort zaken. Dan heb je natuurlijk nog steeds de pass die in normale vorm over een geencodeerde verbinding vliegt, maar met een sniffer heb je daar niet veel aan gezien de SSL beveiliging.

[mjax]

Deze methode kan je wel een vals gevoel van veiligheid geven, aangezien het "security by obscurity" is. Als je op deze manier wilt voorkomen dat een gebruiker variabelen wijzigt in de aanroep, ben je verkeerd bezig.

[gorgi_19]

Verwijderd schreef op 24 oktober 2003 @ 17:06:
POST is opzich een oplossing ja, maar dan heb je nog dat er bijv. een password ongecodeert over het netwerk vliegt... En dus kan iedereen met een sniffer je pass. zien...

Dat hoeft ook nog niet eens veilig te zijn. Ik kan ook vanaf buitenaf proberen om de site te bereiken, via een dummy pagina proberen te posten (en tussendoor dus een 'tussenpagina' maken, die gebruikers invullen en zo dus een wachtwoord 'afvangen', zonder dat iemand het ooit door heeft.

Verder is POST compleet nutteloos als er gebruik gemaakt gaat worden van

ASP:

Dim iAantal
iAantal = Request("aantal")

[Johnny]

Verwijderd schreef op 24 October 2003 @ 17:06:
POST is opzich een oplossing ja, maar dan heb je nog dat er bijv. een password ongecodeert over het netwerk vliegt... En dus kan iedereen met een sniffer je pass. zien...

Als iemand antwoord: svp ook voor JSP/EJB (struts)?

Sessiontracking mag niet via cookies (vindt ik)... sommige mensen kiezen ervoor geen cookies te gebruiken, dan zouden ze dus geen gebruik kunnen maken van je site...

Sessiontracking zou ik liever in de http-session willen zetten..

Tenzij je een heel erg specifieke doelgroep hebt zou gewoon sessies gebruiken hoor. Cookies bestaan al zo lang dat iedereen ze kan gebruiken, ook (vrijwel) alle browsers voor PDA's van de afgelopen 5 jaar ondersteunen cookies.

Daarnaast zijn cookies inmiddels zo algemeen gebruikt dat iemand die geen cookies gebruikt bijna onmogelijk kan surfen en dus wel gedwongen is ze te gerbuiken.

[Eelke Spaak]

Nu zie ik regelmatig ge-encode informatie in de volgende vorm:
{61F9C32E-FE5E-4745-AA83-230D5E34E0CD}

Volgens mij is dit een class-id van een ActiveX control/COM-component of zoiets, en niet een manier om een query-string te encoden.

[B-Man]

mjax schreef op 24 oktober 2003 @ 19:31:
Deze methode kan je wel een vals gevoel van veiligheid geven, aangezien het "security by obscurity" is. Als je op deze manier wilt voorkomen dat een gebruiker variabelen wijzigt in de aanroep, ben je verkeerd bezig.

Ik heb inmiddels al tweemaal vermeld dat het security is, aangezien ik de input valideer en controleer zodra deze ontvangen wordt aan de andere kant (PHP), en dit is waterdicht, en draait inmiddels al drie jaar zonder enig probleem.

Maar goed, hebben we het wederom helemaal niet over mijn oorspronkelijke vraag.

Volgens mij is dit een class-id van een ActiveX control/COM-component of zoiets, en niet een manier om een query-string te encoden.

Dat kan ja, maar het wordt toch ook gebruikt als sleutel voor zaken in databases, zo kreeg ik een paar dagen geleden een mailtje van een bedrijf (e-mail marketing pakket werd aangeboden, mail verzonden door hun eigen pakket), en zag in de broncode van de e-mail, in de headers, o.a. het volgende staan:

code:

Importance: Normal
MemberID: {4368DA96-F922-4959-946D-53C29C89C623}
CampaignID: {61F9C32E-FE5E-4745-AA83-230D5E34E0CD}
Message-ID: <NSG1Zz7dzdVtVKHMzSK0000088c@NSG1>

Zij gebruiken ipv getallen van dit soort sleutels. Nu kan het zo zijn dat dit simpelweg unieke codes zijn, die geen informatie "bevatten", dan nog zou ik graag willen weten hoe ik deze sleutels kan genereren. Het is dan geen encoding/decoding van URIs meer, maar bijvoorbeeld het opnemen van een zo'n sleutel in de URL die verwijst naar een database record waar alle detailinformatie te vinden is.

offtopic:
Dus svp geen discussie meer over veiligheid, security by obscurity, enz. Ik ben op de hoogte van al dit soort zaken.

[Soultaker]

Het zijn inderdaad identifiers; beter gezegd: globally unique identifiers (GUID's). Iets vergelijkbaars kun je doen met PHP's uniqid-functie, maar het resultaat daarvan heeft een wat ander formaat.