[PHP] log in via url

[Verwijderd]

Kan er iemand mij op weg zetten hoe PHP-code aan te passen zodat het voor gebruikers mogelijk wordt in te loggen dmv het doorgeven van username / password in de URL. (Ik weet dat dit wat veiligheid betreft geen beste oplossing is)

[kKaltUu]

met GET, maar hoezo heb je dit niet kunnen vinden door een grote boze zoekmachine te gebruiken?

[xh3adshotx]

PHP:

if ($_GET['UserName'] == "gebruikersnaam" && $_GET['PassWord'] == "wachtwoord")
{
    echo "Yeey";
}
else
{
    echo "Fail";
}

Edit: kKaltUu was me voor.

[ Voor 9% gewijzigd door xh3adshotx op 16-03-2012 15:40 ]

[Pmleader]

Dit kan vrij makkelijk door je POST te vervangen of aan te vullen met GET. je kan ook REQUEST gebruiken.

Edit: en er waren 2 mensen mij voor

[ Voor 15% gewijzigd door Pmleader op 16-03-2012 15:41 ]

[SinergyX]

Puur afhankelijk van het loginscript zelf, maar met de _GET functie kan je al een heel eind komen

Werk je met een @ user/pass voor de URL, kan je dat nog doen via parse_url functie.

[MuddyMagical]

[weg]

Bij nader inzien ga je maar lekker zelf zoeken in plaats van simpel te vragen. Zelfredzaamheid is een zegen!

[ Voor 89% gewijzigd door MuddyMagical op 16-03-2012 15:42 ]

[xh3adshotx]

MuddyMagical schreef op vrijdag 16 maart 2012 @ 15:41:
URL: index.php?username=piet&password=wachtwoord

PHP:

$username = mysql_real_escape_string($_GET['username']);
$password = sha1($_GET['password']);

if( $username == 'piet' && $password == sha1('wachtwoord') ) {
echo('Ingelogd);

}else{
echo('Fail');
}

Misschien heeft het een goede reden, maar waarom real_escape je een GET variable als je niks met je database doe?

[MuddyMagical]

xh3adshotx schreef op vrijdag 16 maart 2012 @ 15:42:
[...]
Misschien heeft het een goede reden, maar waarom real_escape je een GET variable als je niks met je database doe?

Hmm, zo werk het verwijderen van mijn bericht niet.

Maar dit is puur een if die checkt of de variabelen goed zijn ingevuld. De term 'Inloggen' is natuurlijk veel groter en daarvoor heb je toch echt een sessie of cookie nodig. Dus ik hoop dat de TS zelf ook nog wat inzet toont en de rest van de code zelf comleet maakt met een stukje database code, sessie beheer, cookie afhandeling, foutcontrole, etc...

[ Voor 7% gewijzigd door MuddyMagical op 16-03-2012 15:45 ]

[xh3adshotx]

MuddyMagical schreef op vrijdag 16 maart 2012 @ 15:44:
[...]

Hmm, zo werk het verwijderen van mijn bericht niet.

Maar dit is puur een if die checkt of de variabelen goed zijn ingevuld. De term 'Inloggen' is natuurlijk veel groter en daarvoor heb je toch echt een sessie of cookie nodig. Dus ik hoop dat de TS zelf ook nog wat inzet toont en de rest van de code zelf comleet maakt met een stukje database code, sessie beheer, cookie afhandeling, foutcontrole, etc...

Haha, ok. Nee, maar het was niet om jouw post af te zeiken maar ik dacht dat het misschien nog toegevoegde waarde had. Meer een vraag om misschien iets te leren.

[SinergyX]

Als je buiten dit script natuurlijk wel gewoon mysql queries hebt lopen die je dan per ongeluk niet goed beveilig, kan je alsnog via deze get dingen op de database doen. Standaard beveiliging toepassen, dit geval kan het op een GET ook geen kwaad.

[MuddyMagical]

xh3adshotx schreef op vrijdag 16 maart 2012 @ 15:47:
[...]

Haha, ok. Nee, maar het was niet om jouw post af te zeiken maar ik dacht dat het misschien nog toegevoegde waarde had. Meer een vraag om misschien iets te leren.

Geen probleem.
Maar als je een goede start wilt en niet bang bent voor een uitdaging: crisp in "[PHP] BeveiligingsTips nodig"

[TRON]

@TS, waarom jou je dit willen doen? Als je je bezoekers wil laten inloggen vanuit een mailtje (voorbeeld) kan je ook een unieke key genereren waarmee men eenmaal kan inloggen.

[Janoz]

Verwijderd schreef op vrijdag 16 maart 2012 @ 15:36:
....(Ik weet dat dit wat veiligheid betreft geen beste oplossing is)

En toch ben ik ontzettend benieuwd waarom jij denkt dit nodig te hebben. In het kort kun je dit je gebruikers niet aan doen. Je gooit het wachtwoord te grabbel bij onderandere:
- browser historie
- tussenliggende proxies
- logs op de clients
- logs bij de server
- enz enz


Wat is de usecase die je aan het implementeren en waarom denk je dat het niet anders opgelost kan worden?

[ibmos2warp]

SinergyX schreef op vrijdag 16 maart 2012 @ 15:49:
Als je buiten dit script natuurlijk wel gewoon mysql queries hebt lopen die je dan per ongeluk niet goed beveilig, kan je alsnog via deze get dingen op de database doen. Standaard beveiliging toepassen, dit geval kan het op een GET ook geen kwaad.

Nee, mysql_real_escape_string past wel de data aan. Dit gebeurd in zo'n vorm dat als je de data ophaalt lijkt alsof het niet gebeurd is. Als je mysql_real_escape_string gebruikt en je gebruikt daarna een if statement om die variabele te controleren heb je kans dat die if statement niet meer werkt, zie ook

PHP:

mysql_real_escape_string

.

Verder is het natuurlijk ook zo dat je netjes hoort te programmeren en dus weet waar je variabelen veilig zijn en wanneer niet. Bijvoorbeeld door overal de $_GET waarde gebruiken totdat je echt hem moet 'beveiligen' tegen sql injections e.d.
Ook kan je in plaats van escapen gewoon [google]prepared statements[/google] gebruiken, wat weer een heel stuk netter is.

[Verwijderd]

@TRON / Janoz:


Huidige situatie: frontend die vrij toegankelijk is + backend die enkel beschikbaar is na inloggen.

Nieuwe situatie: frontend in drupal waar gebruikers om bepaalde info te kunnen zien moeten inloggen + reeds bestaande backend (welke nog steeds login vereist)


Ik wil voorkomen dat gebruikers 2x moeten inloggen. Op de frontend staat een link naar de backend, als men daar op klikt zou men meteen ingelogd moeten zijn.

[Alwinonline]

kan dat niet beter met een sessie? ik heb niet zoveel ervaring maar volgens mij moet dat kunnen

[martijnve]

Kun je dat niet implementeren met een "formulier" met een submit-knop en twee hidden velden? Dat is nogsteeds slecht maar al een stuk beter.

Als je het helemaal goed doet maakt de server van het nieuwe systeem een sessie aan op het oude systeem, logt in, en speelt de gebruiker dan door naar de nieuwe server met de sessie-id. Op die manier heb je nooit ergens het wachtwoord in plain-tekst in de html staan.

[Verwijderd]

Alle info hieromtrent is welkom.

We zijn tevens van plan om een functie in onze software in te bouwen waardoor het mogelijk wordt dat deze licenties van de server ophaalt. Hiervoor zouden we gebruikers hun login / password laten invullen in de software en het programma in contact laten treden met de site.

[TJHeuvel]

De oplossing die jij oppert kan niet, aangezien je het wachtwoord van de gebruiker na het inloggen niet meer in plain-text weet...

Toch?

Heeft Drupal niet gewoon een API zodat je kan zorgen dat je maar 1 inlog systeem hebt.

[ Voor 24% gewijzigd door TJHeuvel op 16-03-2012 16:23 ]

[Janoz]

Heb je controle over de backend? Zorg dan dat je iets in bouwt waarbij de frontend de gebruiker over kan dragen naar de backend middels een token oid. Klinkt ingewikkeld, maar is heel simpel.

Om naar de backend te linken link je naar een specifieke url in de frontend. Deze genereert een token (gewoon een random string die maar lang genoeg is) en geeft door aan de backend dat gebruiker X zo met het gegenereerde token aan komt zetten. Vervolgens stuur je de gebruiker door naar de backend samen met dit token.

De backend hoeft het token maar even te onthouden (hoeft maar een paar seconden geldig te zijn) en hoeft alleen maar te onthouden welk token bij welke gebruiker hoort. Wanneer dan een gebruiker binnenkomt met dat token dan kun je die automatisch ingelogd laten zijn.

Dit werkt zolang je op 2 dingen kunt vertrouwen:
1 - de frontend weet wie de gebruiker is (dit is afgevangen doordat de gebruiker in de frontend ingelogd heeft)
2 - de communicatie tussen frontend en backend veilig is (Dit is makkelijk te ondervangen door bijvoorbeeld het accepteren van een token door de backend enkel toegankelijk te maken voor het IP van de frontend, of uberhaupt de communicatie te regelen via interne kanalen)

Maar het allerbelangrijkste lijkt me dat jullie eerst goed gaan nadenken over de consequenties van hetgeen jullie nu aan het implementeren zijn. Met een instelling als 'we weten dat het niet veilig is maar het werkt' en daarna 'he, met dit systeem kunnen we ook makkelijk licenties uitdelen' is de kans redelijk aanwezig dat jullie de volgende headline worden in yet another prive gegevens op straat liggend debacle.

[kwaakvaak_v2]

Heeft Drupal niet gewoon een API zodat je kan zorgen dat je maar 1 inlog systeem hebt.

Ja dat heeft drupal idd.. keyword is user_authenticate of user_external_login_register

De truuk is dat je er voor moet zorgen dat de drupal + ander CMS systeem een shared session object of iets dergelijks moeten krijgen ipv vieze URL constructies.

maar goed.. ik hoop dat het backend systeem niet een ander CMS is, want anders klinkt het wel als een redelijke vreemde situatie en zou ik eerder er voor kiezen om authenticatie in het andere systeem te bouwen, of alle CMS functies richting drupal verplaatsen.

[Verwijderd]

@Janoz : Met je onderste alinea kan ik jammer genoeg enkel maar akkoord mee gaan

Ga Googlen om meer info te vinden ivm het token-verhaal