• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Sessions und Passwort

I

Iltis

Lounge-Member
Ich habe wieder einmal ein Problem mit PHPlib.

Und zwar habe ich bei meiner Seite ein Adminbereich den ich mit PHPlib mit Passwort schütze. Ich brauche in meiner PHPlib GET SESSIONS und daher müsste ich also alle links so schreiben, die in der Adminseite sind:

<a href="<?php $sess->purl("/seite.php")?>">gehe zur Seite</a>

Wenn ich es so mache wird zwar die Session weitergegeben aber nicht der Username, Passwort und Benutzerrechte. Was zur Folge hat, dass ich mich bei jeder Seite im Admin Bereich neu einloggen muss.

Falls euch das noch hilft, am Anfang im code steht bei mir auf jeder Seite im Adminbereich das:

<?php page_open(array("sess" => "session",
"auth" => "Example_Auth",
"perm" => "Example_Perm"));
$perm->check("admin");
?>

Vielen Dank für eure Hilfe
 
doofe frage zwar aber...

Wieso gibts den Password und Benutzername net mir Cookies über?? Bevor man das PW in den Cokkies abspeicher noch ne md5(); verkrüptung und das halt abfrage if(Password==Normal_Passowrd OR Password==Cryptische_Password) { dann etcc....................

also so würd ichs machen
 
endlich hatte ich ein bisschen zeit an meinem forum herumzubasteln.

Nun an die cookies habe ich auch gedacht. nur habe ich in PHPlib an sämtlichen Orten versucht ein Cookie einzubauen, doch erfolglos. Kann mir jemand sagen wo ich das cookie einbauen muss?
 
Hi Iltis,

Also md5 hin oder her, Passwort und Login im Cookie zu speichern ist völliger Blödsinn! Eine Session ID ist völlig ausreichend gerade bei einer Lib wie der phplib!!!

Schau dir mal die Datei local.inc aus der PHPLib genauer an. Dort kannst Du nämlich eine Klasse von Auth ableiten (siehe Beispiel "Example_Auth") und diese entsprechend Deinen Bedürfnissen (sprich DB Tabellen und Bezeichungen) anpassen. Passwort, Username und Permissions werden im $Auth Objekt gespeichert.
Für eigene Permissions mußt Du zusätzlich noch eine Klasse von Perm ableiten (siehe "Example_Perm"). Prinzipiell spielt sich aber alles in local.inc ab. Die von Auth abgeleitete Klasse ist auch die, welche die URL von Deiner Login Form enthält.

Schaus Dir einfach noch mal an und les auch die Online Hilfe, dann sollte das eigentlich klappen!!

Ciao,

Albu
 
Ciao Albu,

ich werde es mir mal anschauen, denn ich hatte mir schon lange gedacht dass sessions reichen nur hats bei mir nie die perms und auths mit der session gespeichert.Vielen Dank
 
Es geht auch einfacher

Klären wir erst einmal die Situation:

PHP4 mit Sessions ist vorhanden, oder? Wenn ja dann mach die ganze geschichte einfach so hier:

In jede Datei die geschützt sein soll kommt als allererstes ein

<?php require ("security.php"); ?>

In dieser Datei security.php werden folgende Befehle ausgeführt:

<?php
@session_start();
if ( isset($username) && $username != "" && isset($password) && $password != "" )
{
#Name und Passwort überprüfen
if ( $username == "admin" && $password == "pw" )
{

} else HEADER ("Location: login.php");
} else HEADER ("Location: login.php");

?>

So ähnlich funktioniert es. Ich kann Dir, wenn Du willst, ein passendes von mir geschriebenes Script zur Verfügung stellen, habe es aber im Moment nicht hier. Nur um den Gedanken noch abzuschließen, in der Login.php müssen noch 2 Formularfelder sein, welche das Login darstellen, in der Datei, an die Verwiesen wird, muss einfach noch drinstehen:

@session_start;
session_register ("username","password");
HEADER ("Location: index.php");

In der index.php wird ja wieder die secure.php eingebunden und daher auch geprüft ob die Passworter in der Session stimmen, wenn nicht geht's zurück zur Anmeldung und wenn die stimmen, dann kann man eben die Seiten betrachten...

Gruß
Melzi
 
@melzi: natürlich kann man auch alles von Hand coden, aber wenn es sowas schon gibt und es noch dazu genauso einfach einzusetzen ist, dann ziehe ich doch die PHPLib vor. Schließlich bietet sie noch mehr als nur Session Management (und das schon mit PHP3!! ). Man kann z.B. relativ schnell und ohne größere Code Änderungen auf eine andere Datenbank umsteigen, da man hier nur eine Datei umbiegen muß. (Natürlich sollte man dann auf Spezial-DB-Funktionen wie z.B. LIMIT verzichten, sonst muß man seinen Code doch noch mal anfassen).
Das Generieren von Formularen ist mit der PHPLib auch ziemlich einfach und elegant lösbar. Ganz zu schweigen von den Templates.

Also Dein Code funktioniert bestimmt, aber die Login Maske und die Zugriffe auf die DB zum Überprüfen des Users und Passwortes mußt man in Deinem Beispiel selbst programmieren und das ist genau der Teil, den man in der PHPLib auch programmieren muß, mit der Ausnahme, daß es für das meiste schon Beispiele gibt.
Vielleicht muß man sich als prozeduraler Programmierer mit Objekten und Klassen rumschlagen, aber das ist nur ein kleiner Schritt, der durch die vielen Vorteile einer Lib wie der PHPLib wieder wettgemacht werden....

so genug Werbung....

Albu
 
Die Code-Schnipsel, die ich hier hingeworfen habe, sind nur Auszüge, ich bin gerade dabei ein echt großes Projekt umzusetzen, dort habe ich ein extrem sicheres Anmeldeverfahren auf Basis des oben genannten Codes entwickelt, natürlich arbeitet mein Script mit einer Datenbank und das Formular und der Rest sind auch dabei, es sollte auch nur als Denkanstoß dienen... ;-)

PHPLib hab ich zwar noch nicht verwendet, brauch ich aber auch nicht, da ich so ein oldschool progger bin, alles selber machen, auch wenn man es an jeder Ecke kostenlos bekommt....

Gruß
Melzi
 
@melzi: ich zweifele gar nicht an, daß dieser Code funktioniert. Meine Aussage ist nur, daß die PHPLib eigentlich genau das gleiche macht, allerdings einige Erleichterungen mit sich bringt. (wie z.B. Sessions unter PHP3, DB Unabhängigkeit, Formulare, Templates, usw....)

Wenn Du alles von Hand programmieren willst, dann bitte schön, ich ziehe eine Lib vor, wenn sie mir Arbeit abnimmt und sie noch dazu objektorientiert ist.
Schließlich benutzt Du unter Windows auch ODBC und programmierst nicht die Datenbank direkt, oder??
Natürlich ist ein selbstprogrammiertes Stück Software viel toller als alles im Laden erhältliche, aber man sollte hier schon abwägen, ob Aufwand, Zeit und Mühe lohnt und welche Nachteile man sich dadurch erkauft. (Ein in seinen Code verliebter Programmierer macht noch keinen zufriedenen Kunden ;) ).
Nehmen wir ein Beispiel: Dein großes Projekt geht online, die verwendete mySQL Datenbank geht in die Knie, weil der Ansturm zu groß ist, der Kunde sagt, ok stellen wir einen Oracle Hobel hin. Was machst Du?
a.) Du tauscht Deine selbstentwickelte Datenbank Schicht aus, indem Du eine neue DB Klasse schreibst?
b.) Du tauscht die Datenbank Schicht einer Lib aus (z.B. PHPLib)
c.) Du machst einen Search & Replace auf Deinen gesamten Projektordner?
Oldschool hin oder her, eine was der Bauer ned kennt.... Strategie ist nicht immer von Vorteil.....

Ciao,

Albu
 
Albu schrieb:
Hi Iltis,

Also md5 hin oder her, Passwort und Login im Cookie zu speichern ist völliger Blödsinn!
Zum Vergrößern anklicken....
Ok dann mal anderst. Er meldet sich an. Macht was un geht dann erst mal ein kaffe trinken. Dafür brauch er 25 min. Nun kommt er wieder will weiter schaffen aber die Session is weg weil sie nach 24 min. inaktivität (PHP Standarteinstellung) nicht mehr vorhanden ist. Nun haette er dat mit Cookies gemacht wäre das nicht passiert.
So nun erzähl mir mal ein richitgen Grund warum VBB und andere Foren das so handhaben?? Weils Blödsin is.
 
Also, mit Cookies finde ich nicht gerade sehr toll, stellt euch doch einmal folgendes vor:

Jemand geht Kaffee trinken und lässt den Passwortgeschützen Bereich offen, jetzt kann jeder darin rumpfuschen, wie er will, ist doch völliger blödsinn! Sobald es um etwas ernstes geht, dann sollte das Script schon nach 5 Minuten inaktivität nach dem Passwort fragen...

Gruß
Melzi

P.S.
Klar kann es mit OldSchool zu Problemen kommen, aber das Projekt ist in der hinsicht groß, da es mehrfach verkauft wird, also das Script...
 
@klark: es geht hier um den Admin Bereich (vermutlich einer Webseite). Der Admin geht also mal schnell 24 Minuten Kaffee schlürfen, kommt wieder, arbeitet weiter, macht Feierabend... Sein Kollege wartet bis er weg is, setzt sich an den Rechner benutzt die Cookies des Admins und kann so mal lustige Änderungen auf den Seiten machen..... auch lange nach dem Feierabend des Admins hinaus
Anderes Beispiel: der Kollege setzt einen Protokoll Sniffer ein, horcht die Kommunikation zwischen Admin und Proxy ab, bekommt so Zugriff auf das MD5 Passwort und seinen Login Namen und kann sich einen entsprechenden Cookie herstellen....
Und das alles nur, weil der Admin so ein Schlunzi ist und sich ned mal seine 5 Passwörter merken kann....

Ich denke es kommt immer darauf an, was man mit dem Passwort schützen möchte. Sitze ich zuhause allein vorm Rechner und kommt da sonst keiner dran, dann kann ich auch ein Passwort in nem Cookie unterbringen. Bei kritischeren Sachen würde ich mich hüten.
Vor allem wenn es z.B. mehrere Rollen gibt, dann ist das ganze eher lästig, d.h. z.B. Admins, Editoren, normale User, alle mit unterschiedlichen Rechten ausgestattet und alle loggen sich über die selbe Maske ein. Ein AutoLogin mit Cookies führt dazu, daß man ständig mit dem falschen Login drinne ist, weil man z.B. mal die Admin Sachen aufrufen muß, mal Editoren testen muß und mal die Normal User durchchecken muß.

@Melzi: gerade wenn es verkauft werden soll, könnte ein bißchen Flexibilität nicht schaden, zumal es ein zusätzliches Verkaufsargument wäre.....

P.S.: die Cookies hier in dem Board funktionieren neuerdings gar nicht mehr gescheit (zumindest im Opera!!)
 
Also

Das ganze wird mal eine Gebrauchtwagendatenbank speziell für größere Gebrauchtwagen- bzw. Reimporthändler. Die gesamten Scripte werden auf meinem Server gehostet und auf Wunsch kann dann auch noch an einer großen "Sammeldatenbank" in der alle "freigegebenen" PKW angezeigt werden teilnehmen, das ganze nennt man dann aktive Verkaufsförderung auf höchstem Niveau mit neuester Technik.

Das Anmeldescript habe ich nun noch etwas mehr verschärft, es kickt den User sobald er 4 Minuten inaktiv war, damit gibt es zwar noch ein paar Probleme, aber ich bastle ja auch noch dran.

Es ist immer abzuwägen, wie sicher etwas sein soll und ob ein Login überhaupt nötig ist. Eins steht für mich jedoch fest, sobald ich mir etwas selbst programmiere, kann ich jederzeit etwas daran ändern und es meinen Wünschen und Vorstellungen anpassen, ganz anders bei fertigen Scripten, oder Libs, dort muss man sich immer erst reinarbeiten bis man etwas umschreiben kann und irgendwann stellt man fest, dass die Änderung so umfangreich ist, dass man es hätte auch selbst proggen können...

Gruß
Melzi
 
@Melzi: wenn ich nur ein einziges Benutzerrecht hätte auf einer Seite, dann würde ich auch selber coden. Jetzt ist es aber so, dass ich auf einer Seite 6verschiedene Foren habe mit verschiedenen Benutzerrechten. Und da geht es für mich immer noch schneller mit der PHPlib

<?php page_open(array("sess" => "session",
"auth" => "Example_Auth",
"perm" => "Example_Perm"));
$perm->check("admin oder andere");
?>

am Anfang jeder Seite einzufügen und ein paar Änderungen zu machen in der Lib anstatt alles selber zu coden.
Nebst der Sicherheit die PHPlib bietet.

Gruss Iltis
 
@Melzi: Natürlich muß man sich bei einer Lib auf den Autor verlassen und hoffen, daß der alles richtig gemacht hat, aber dafür ist der enthaltene Code auch mehrfach getestet und auf vielen hunderten oder tausenden von Seiten aktiv. Können die alle irren?
Klaro muß man sich in eine Lib einarbeiten, in jede Lib die ich verwende muß ich mich reinarbeiten. Und in den wenigsten Fällen liegt der Source Code dazu vor!!
Und was ist, wenn Du noch einen Mitarbeiter dazu bekommst, der mitprogrammieren soll? Eine Lib wie die PHPLib sollte man als PHP Programmierer schon kennen, Melzi-Super-Duper-Spezial-Funktionen-Lib kennt nur eine einzige Person....

Zum Thema neueste Technik: Neueste Technik ist Multi-Tier.... Du hast doch Code, Darstellung und DB-Zugriffe getrennt?? Noch besser ist natürlich das Ganze auf Middleware Technologie aufzusetzen, mit einem gescheiten Application Server und am besten EJBs oder .NET....
PHP ist mir persönlich zwar lieber als Perl oder gar ASP, aber es eignet sich eben nur für kleinere bis mittlere und manchmal sogar für große Projekte, aber die ganz großen Projekte werden mit Servlet, EJBs oder .NET gemacht. (geh mal zu ner Bank und erzähl denen, ihr neuer Kundenbereich wird in PHP realisiert....)
 
Für meine Zwecke reichts ja auf jeden Fall, mit den Benutzerrechten ist ein kleiner 20 Zeilen Code und damit kann ich alles schützen, bis in's kleinste Detail, ich kann sogar einzelne Textfelder oder Checkboxen sperren, wenn ich es wöllte und es sinn machen würde. :D

Natürlich hätte ich kaum Chancen bei so großen Firmen, aber mobile.de schlage ich mit meinem Script sicherlich. Bei mir geht es wenn es fertig ist, dann schon an ganze Finanzierungsbeispiele usw. Da ich aus dem Automobilgewerbe komme, habe ich in der Hinsicht Erfahrung und ich kenne mich auch mit solchen "Börsen" aus und daher denke ich, dass wenn mein PCS fertig ist, es schon anklang findet.

Ich will auch niemals irgendjemanden damit übertreffen, es soll einfach nur meinen Bedürfnissen und die Bedürfnisse meiner Kunden abdecken, naturlich auch mein Portmoney etwas füllen, aber das ist mir nicht soo wichtig...

Gruß
Melzi

P.S.
Wenn Ihr wollt, könnt Ihr das ganze auch testen, dauert noch ein weilchen bis es dafür bereit ist, aber wenn es soweit ist gebe ich bescheid...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben