Verbindungen erhalten

[Druid]

Wir haben folgendes Problem:

Wir übergeben den Benutzernamen über eine CGI-Variable (window.open('beispiel.php?var=$benutzer', target='_self').

Am Anfang wird gleich eine permanente Verbindung zum MSSQL-Server aufgebaut mit mssql_pconnect().. Nachdem, die Variable, an die Zielseite gelangt ist, ist die Verbindung aber auch schon wieder weg..

Mann müsste nochmal eine Verbindung aufbauan und dazu müsste man das Passwort mit übergeben.. Dies geht aber aus Sicherheitsgründen nicht..

Frage:

Wie kann ich eine dauerhafte Verbindung über mehrer PHP-Seiten realisieren, ohne die PHPLIB zu benützen??

DRINGEND!!!!!

THX

DRUID

[lapso]

Original geschrieben von Druid

Wie kann ich eine dauerhafte Verbindung über mehrer PHP-Seiten realisieren, ohne die PHPLIB zu benützen??

DRINGEND!!!!!

http ist verbindungslos.

(Das war schon immer so.)

Gruesse,

Matze

[Druid]

http ist Verbindungslos? Was heißt das jetzt konkret?

Wie machen das z.B. GMX, dass man sich einloggt und auch bleibt...

Bauen die jedesmal wieder eine neue Verbindung zur Datenbank auf, wenn die benötigt wird?? :confused:

Ich habs jetzt mit CGI-Variablen und Base64-Codierung gemacht, das ging auch, ist halt net so sauber *g*

Was hat das mit den Sessions auf sich.. Ist es also nicht möglich eine Session über den Aufenthalt auf einer Website aufrecht zu erhalten??

MFG

Druid

[lapso]

Original geschrieben von Druid

http ist Verbindungslos? Was heißt das jetzt konkret?

Wie machen das z.B. GMX, dass man sich einloggt und auch bleibt...

Bauen die jedesmal wieder eine neue Verbindung zur Datenbank auf, wenn die benötigt wird?? :confused:

Ich habs jetzt mit CGI-Variablen und Base64-Codierung gemacht, das ging auch, ist halt net so sauber *g*

Was hat das mit den Sessions auf sich.. Ist es also nicht möglich eine Session über den Aufenthalt auf einer Website aufrecht zu erhalten??

aaaalso Blumen&Bienen.

http ist insofern verbindungslos, als dass keine permanente Verbindung zwischen Client und Server zwischen zwei Requests besteht. Eine Verbindung existiert i.d.R. nur solange, wie eine Datei(HTML, GIF usw.) vom Client zum Server übertragen wird - dafür steht http.

d.H.: Wenn ich eine Seite aufrufe(Request), erhalte(Response) und anzeige, danach einen Link darin zu einer weiteren Seite anclicke, hat dieser zweite Seitenaufruf nichts mehr mit dem ersten zu tun. Der Webserver kann erstmal nicht erkennen, dass ein Zusammenhang zwischen den beiden Requests besteht; erst recht kann er dich nicht als User identifizieren, denn alles was er hat ist deine IP-Adresse (die nicht zur Identifikation genügt).

Das ganze hat auch erstmal nichts mit einer Datenbank zu tun; Der Client kommuniziert schließlich nicht mit ihr, sondern der Webserver tut das.

Um nun - wie z.B. bei GMX - eine Sitzung(Session) zu verwenden, anhand welcher die eigentlich unabhängigen Requests einem Benutzer (einer Browserinstanz) zugeordnet werden können, muss die Browserinstanz sich eindeutig identifizieren lassen. Er benötigt also eine ID, die dem Webserver bekannt ist, und er muss diese ID bei jedem Request dem Webserver mitteilen, damit dieser den Request einer Session zuordnen kann.

Hierzu sind zwei Methoden gebräuchlich:

- Die Cookie-Methode: Der Webserver sendet ein sogenannten Session-Cookie, welcher eine ID enthält. Der Browser sendet bei jedem Request den Cookie im http-Header zurück, sodass der Server anhand der darin enthaltenen ID und seiner internen Session-Verwaltung erkennen kann, zu welcher Session der Request gehört. Der MS-IIS Server benutzt z.B. dieses Verfahren und stellt dem Programmierer damit eine sehr einfache, transparente Session-Verwaltung zur Verfügung.

- Die GET-/POST-Methode: Die Session-ID wird dabei dynamisch in alle Links (z.B. href="zweiteseite.jsp?SID=3874521378") sowie alle Forms integriert, sodass bei einem Request durch diese Links/Forms die ID wieder zum Server übertragen wird. Diese Methode hat eben den Vorteil, dass sie auch ohne Cookies funzt.

Im großen und ganzen macht der Webserver nicht mehr, als zu jeder Session einen Satz Variablen zu verwalten (z.B. UserID, Name); Anhand der Session-ID kann er stets den zur "requestenden" Browserinstanz gehörigen Satz von Daten identifizieren; somit ist es also möglich, personalisierte Dienste über http anzubieten.

Zur Datenbank: Meistens wird innerhalb einer dynamischen Seite (JSP/ASP/PHP....) eine Datenbankverbindung aufgebaut, genutzt und dann wieder geschlossen. Das ist auch sinnvoll, da eine Datenbankverbindung nicht benötigt wird, wenn gerade kein Request bearbeitet wird. Also:

Request->DatenbankÖffnen->Verarbeitung->DatenbankSchliessen->Response

Ich hoffe, dass das erstmal hilfreich und soweit verständlich war,

Grüße

Matthias

[Druid]

Achso.. jetzt wird mir einiges klar..

Ich hab das so ähnlich gelöst, wie du es mir mit den Cookies beschrieben hast..

Beim Aufruf der nächsten Seite übergeb ich durch CGI-Variablen den Username und das Passwort in folgender Form:

window.open('nächsteSeite.php?var=$übergabe', target='_self')

Das funktioniert auch, und so kann ich eine Verbindung wieder aufbauen...

Kannst du mir sagen, ob das eine saubere Methode ist?? (bin noch PHP-Neuling)

Und das http keine permanente Verbindung zwischen Server und Client aufrecht erhält wusst ich schon (hab bloß net geblickt, was du mit Verbindungslos genau meinst )

Wenn man sich jetzt z.B. dieses Forum anschaut, kommuniziert der Webserver mit der DB durch Sessions.. mein Problem ist nur, dass ich keine Sessions benutzen kann, da wir es einfach nicht schaffen die PHP_Lib einzubinden

Aber danke nochmal für deine Hilfe

MFG

Druid

[lapso]

Original geschrieben von Druid

Ich hab das so ähnlich gelöst, wie du es mir mit den Cookies beschrieben hast.. Beim Aufruf der nächsten Seite übergeb ich durch CGI-Variablen den Username und das Passwort in folgender Form: window.open('nächsteSeite.php?var=$übergabe', target='_self') Das funktioniert auch, und so kann ich eine Verbindung wieder aufbauen... Kannst du mir sagen, ob das eine saubere Methode ist?? (bin noch PHP-Neuling)

Auf keinen Fall ist das empfehlenswert. Wollt ihr bei jedem Seitenaufruf Username+Passwort übergeben? Das ist, gelinde gesagt, dumm, aber vor allem überflüssig. Alles, was man braucht, ist eine SessionID. Das Passwort breucht ihr nur beim Login, danach nicht wieder. Ob Ihr nun auf vorhandene Libs zurückgreift oder euch eine eigene schreibt, ist irrelevant, aber Passwörter von Seite zu seite zu geben ist einfach fahrlässig.

Wenn man sich jetzt z.B. dieses Forum anschaut, kommuniziert der Webserver mit der DB durch Sessions..

Nein, der Browser kommuniziert mit dem Webserver, dabei wird stets die Session-ID übergeben (in beide Richtungen). Es existiert also eine Sessino zwischen Server und Client. In diesem Forum hier findet das über ein Cookie statt.

Der Webserver (respektive die dynamischen Seiten darin) kommuniziert mit der Datenbank meistens über ODBC. Hier ist der Webserver nun der "Client" und der DB-Server der "Server". Beide Verbindungen musst du unabhängig voneinander betrachten.

mein Problem ist nur, dass ich keine Sessions benutzen kann, da wir es einfach nicht schaffen die PHP_Lib einzubinden

Dann müßt Ihr euch wohl mal auf den Hosenboden setzen. Vorher sollte man gar nicht erst weiter programmieren, wenn solche grundlegenden Dinge nicht implementiert sind; später wird sonst allzuviel -verdammt viel- Arbeit anfallen.

Ich kenne mich leider mit PHP nicht aus (komme aus der ASP-Ecke), kann dir aber trotzdem nur den Rat geben: Baut erst das Anwendungs-Framework (vor allem das Session-Handling), und macht euch erst danach an die Entwicklung der Funktionen der Anwendung. Und vor allem: Abgesehen vom Login-Request niemals das Passwort übergeben.

Gruss

Matze

[Impulz]

Also die PHPLib is fuer Sessions ziemlich unnoetig. PHP4 hat selber eine Session-Verwaltung drin. phplib hat noch ne auth dabei, aber die machst du vermutlich selber. Das einzig noch nuetzliche an der phplib is imho die template klasse.

Zu Sessions lies dir am besten folgendes durch:

http://www.koehntopp.de/php/version4_session.html

gruss

Impulz

[Druid]

THX Lasgo!!

Wie gesagt ich bin in dieser Schienen noch Neuling

Also werde ich mich erstmal über Session-Handling unter PHP4 informieren, bevor ich weiter programmiere!!!

Auch danke für den Link. ich schau ihn mir gleich mal an..

MFG

Druid

[Druid]

Hallo Lapso!!

Ich habe mich mit Session-Handling auseinandergesetzt und muss sagen, dass unsere Lösung gar nicht so dumm ist...

Vielleicht verstehst du was ich meine, wenn ich es genauer erkläre:

Mit session_start() erstelle ich eine Session inkl. Session-ID..

Mit session_register() weis ich der Session dann Variablen zu udn übergebe durch Cookies die ID!!

So... Punkt 1: In einem weitläufigerem Sinne übergebe ich indirekt auch das Passwort (muss ich ja wohl, sonst kann ich ja keine Verbindung zum SQL-Server mehr aufbauen..)

Punkt 2: Was anscheinend nicht ganz klar geworden ist, ist, dass die ganze Sache an unser Firmennetz angepasst werden muss und in unserem Netz sind standardmässig alle Cookies deaktiviert!! Als Fallback müsste ich also auch die Session-ID per Hand übergeben an jede einzelne Seite! (-> genauso hoher Traffic)

Ich finde, dass es deshalb ziemlich egal ist, ob ich den verschlüsselten Benutzernamen und das verschlüsselte Passwort übergebe, oder eine Session-ID!!! Der Traffic ist in etwa gleich hoch und ich denke nicht, dass es irgendjemnad in der Firma schafft einen 64Bit-Schlüssel zu knacken!!

Aus diesem Grund würde ich unsere Lösung nicht voreilig dumm nennen, bloss weil sie anders ist!!!

Sie ist auch eine Lösung und in diesem Fall sogar die bessere, nach meiner Meinung!!!

MFG

Druid

[Impulz]

Original geschrieben von Druid

So... Punkt 1: In einem weitläufigerem Sinne übergebe ich indirekt auch das Passwort (muss ich ja wohl, sonst kann ich ja keine Verbindung zum SQL-Server mehr aufbauen..)

Hae? Wieso? Wird die Datenbankverbindung mit dem jeweiligen Login des Users aufgebaut?

Als Fallback müsste ich also auch die Session-ID per Hand übergeben an jede einzelne Seite! (-> genauso hoher Traffic)

Das PHP Session-Management hat SIDs per GET als Fallback drin.

Traffic duerfte in nem Firmennetz wohl kaum ne Rolle spielen, insb. wenn es sich um Unterschiede von ein paar Byte handelt.

Ich finde, dass es deshalb ziemlich egal ist, ob ich den verschlüsselten Benutzernamen und das verschlüsselte Passwort übergebe, oder eine Session-ID!!!

Man sollte vertrauliche Daten so selten wie moeglich uebers Netz jagen, Verschluesselung ist hier auch nicht das non-plus-ultra. Jeder der die Seite oeffnen kann, sieht auch die Art der Verschluesselung (da Javascript, anderweitige client-side Verschluesselung duerfte schwierig werden) und kann sie knacken.

Bei ner Session werden die ganzen Daten auf dem Server abgelegt und nur eine Session-ID uebertragen, die keinerlei Auskunft ueber die gespeicherten Daten gibt und deren Gueltigkeit man z.b. zeitlich einschraenken kann indem man ein Timestamp abspeichert wann die Session gestartet wurde.

gruss

Michael

[Druid]

Im Grunde genommen hast du schon recht, aber ich habe keine Lust jetzt alle PHP-Seiten wieder zu ändern!!!

In das interne Firmennetz kommt sowieso nur äußerst schwer jemand rein und somit dürfte eine Verschlüsselung der Daten vollkomen ausrecihend sein..

Die Auslastung des Netzes, wie du auch schon bestätigt hast spielt keine Rolle, also ist es egal!!

Und die Sensibilität der Daten ist nicht allzu hoch!!

Ich danke dir trotzdem für die Hilfe

MFG

Druid