Session Management
Session Management
Hallo,
ich habe ein "kleines" Problem mit dem Sessionmanagement.
Ich habe ein selbstgeschriebenes Backend in Contenido eingebunden und möchte auf die Sessionfunktionalität zugreifen.
Mir ist nicht ganz klar, wie ich meine eigenen Variablen in die Session einbinden kann.
Ich möchte nicht das Objekt $sess benutzen sondern mit $_SESSION oder session_register() die PHP-eigenen Funktionen benutzen.
Es scheint aber so, daß Contenido irgendwie dazwischen funkt......
Gruß
Jose Rodriguez
ich habe ein "kleines" Problem mit dem Sessionmanagement.
Ich habe ein selbstgeschriebenes Backend in Contenido eingebunden und möchte auf die Sessionfunktionalität zugreifen.
Mir ist nicht ganz klar, wie ich meine eigenen Variablen in die Session einbinden kann.
Ich möchte nicht das Objekt $sess benutzen sondern mit $_SESSION oder session_register() die PHP-eigenen Funktionen benutzen.
Es scheint aber so, daß Contenido irgendwie dazwischen funkt......
Gruß
Jose Rodriguez
Contenido benutzt die sessionmethoden der phplib. Diese sind entstanden, da es in php3 noch keine php eigenen sessions gab.
Weitere Informationen hier:
http://www.sanisoft.com/phplib/manual/p ... ssions.php
Weitere Informationen hier:
http://www.sanisoft.com/phplib/manual/p ... ssions.php
Ja, genau, siehe Link oben
Ich werde mir das in nächster Zeit mal ansehen, allerdings frage ich mich immer noch, ob das PHP eigene Sessionmanagment nun schlechter oder besser ist.
Ich denke, dass mit den Abkupfern der PHPlib- Schnittstellen und das entsprechende darüberklatschen der einzelnen "neuen" Methoden ist momentan die sauberste Lösung um neue Funktionen zu implementieren, die eigentlich auf die phplib angewiesen sind.
Weißt Du vielleicht, ob es für PEAR sowas auch für den Datenbankabstraktionslayer und die Auth- Geschichte gibt, dann sind wir die phplib nämlich ganz schnell los.
Ich werde mir das in nächster Zeit mal ansehen, allerdings frage ich mich immer noch, ob das PHP eigene Sessionmanagment nun schlechter oder besser ist.
Ich denke, dass mit den Abkupfern der PHPlib- Schnittstellen und das entsprechende darüberklatschen der einzelnen "neuen" Methoden ist momentan die sauberste Lösung um neue Funktionen zu implementieren, die eigentlich auf die phplib angewiesen sind.
Weißt Du vielleicht, ob es für PEAR sowas auch für den Datenbankabstraktionslayer und die Auth- Geschichte gibt, dann sind wir die phplib nämlich ganz schnell los.
@Björn:
meinst Du das?
Gruss ekke
meinst Du das?
http://pear.php.net/manual/en/packages.auth.phpVIII. Authentication
The PEAR::Auth package helps you to create PHP based authentication systems.
Table of Contents
Auth -- PHP based authentication systems.
Auth_HTTP -- HTTP authentication with PHP.
http://pear.php.net/manual/en/core.db.phpIII. PEAR DB: a unified API for accessing SQL-databases
This chapter describes how to use the PEAR database abstraction layer.
Table of Contents
DSN -- The data source name
Connect -- Connecting and disconnecting
Query -- Performing a query against a database.
Fetch -- Fetching rows from the query
Sequences -- Database sequences
Execute -- Prepare & Execute/ExecuteMultiple
DB::connect() -- Create a new DB connection object and connect to the specified database
DB::disconnect() -- Log out and disconnect from the database.
DB::isWarning() -- Tell whether a result code from a DB method is a warning.
DB::isError() -- Tell whether a result code from a DB method is an error.
DB::quote() -- Quotes a string so it can be safely used in a query
DB::provides() -- Tell whether a DB implementation or its backend extension supports a given feature.
DB::setFetchMode() -- Sets which fetch mode should be used by default on queries on the connection.
DB::prepare() -- Prepares a query for multiple execution with execute().
DB::autoPrepare() -- Build automaticaly an insert or an update sql query and call prepare() with it.
DB::execute() -- Executes a prepared SQL query
DB::executeMultiple() -- Several executes a prepared SQL query
DB::query() -- Send a query to the database
DB::limitQuery() -- Generates a limited query EXPERIMENTAL!
DB::getOne() -- Fetch the first column of the first row from a query
DB::getRow() -- Fetch the first row from a query
DB::getCol() -- Fetch a single column from a query
DB::getAssoc() -- Fetch the result set as an associative array using the first column as the key.
DB::getAll() -- Fetch all the rows returned from a query.
DB::affectedRows() -- returns the affected rows of a query
DB::nextId() -- returns the next free id of a sequence
DB::createSequence() -- creates a new sequence
DB::dropSequence() -- deletes a sequence
DB::getListOf() -- list internal DB info
DB_Result -- contains the result of a database query
DB_Result::fetchRow() -- Fetch and return a row of data
DB_Result::fetchInto() -- Fetch a row of data into an existing variable.
DB_Result::numCols() -- Get the the number of columns in a result set.
DB_Result::numRows() -- Get the the number of rows in a result set.
DB_Result::nextResult() -- Get the next result if a batch of queries was executed.
DB_Result::free() -- Frees the resources allocated for this result set.
DB_Result::tableInfo() -- returns meta data about the result set
DB_Error -- Class for reporting portable database error messages.
DB_Warning -- Class for reporting portable database warning messages.
Gruss ekke
Ja, geht schon in die richtitge Richtung.
Ich meinte aber mehr Wrapper-Klassen, die diese Funktionalität als phplib- Schnittstelle zur Verfügung stellen. Ist eigentlich auch recht schnell selbst gemacht, allerdings muß man sich bei fertigen Sachen nicht so in die Materie reinvertiefen und die Bedeutung einer jeden Variablen wissen.
Ich denke mit dem Aufkommen des PEAR hat die phplib ausgedient und man sollte sich überlegen, ob es nicht besser ist umzusteigen.
Ich meinte aber mehr Wrapper-Klassen, die diese Funktionalität als phplib- Schnittstelle zur Verfügung stellen. Ist eigentlich auch recht schnell selbst gemacht, allerdings muß man sich bei fertigen Sachen nicht so in die Materie reinvertiefen und die Bedeutung einer jeden Variablen wissen.
Ich denke mit dem Aufkommen des PEAR hat die phplib ausgedient und man sollte sich überlegen, ob es nicht besser ist umzusteigen.
vielleicht könnte man ja über eine "doppel"-belegung nachdenken.
sprich: sowohl phplib als auch pear.
ich könnte mir vorstellen die funktionalität über config/ini zu steuern.
allerdings müssten contenido-spezifische wrappers geschrieben werden.
die wrapper-lösung hätte den vorteil einer contenido-schnittstelle. dies wäre für erweiterungen sehr hilfreich, oder?
gruß
jose rodriguez
sprich: sowohl phplib als auch pear.
ich könnte mir vorstellen die funktionalität über config/ini zu steuern.
allerdings müssten contenido-spezifische wrappers geschrieben werden.
die wrapper-lösung hätte den vorteil einer contenido-schnittstelle. dies wäre für erweiterungen sehr hilfreich, oder?
gruß
jose rodriguez
Hm- ich habe mit pear noch nie richtig gearbeitet, vor allem wegen der schlechten Dokumentationslage vor einiger Zeit. Das scheint sich ja jetzt geändert zu haben. Die perm_LiveUser-Klasse ist ja schon ziemlich interressant, im Gegensatz zur Phplib gibts da z.B. Gruppenrechte, das hatte ich immer vermisst.
Ich hatte mal testweise phpwebsite .9x laufen, da hatte ich den Eindruck, daß Pear etwas unter Performance-Problemen leidet. Hat jemand da Erfahrungen gesammelt?
Steff
Ich hatte mal testweise phpwebsite .9x laufen, da hatte ich den Eindruck, daß Pear etwas unter Performance-Problemen leidet. Hat jemand da Erfahrungen gesammelt?
Steff
@JRod
Eine Doppelbelegung mit Wrapperklassen würde bei mir so aussehen: Die Klasse hat die gleichen Schnittstellen wie die phplib, damit ist dann der gesamte Unterbau kompatibel.
Nutzt man die phplib, ist der Wrapper unnötig, da sowieso alles über die phplib geregelt wird.
Nutzt man PEAR kommen die Wrapper hinzu.
Für die Version 4.4 con Contenido wäre dies für mich OK, später sollten aber nach und nach alle Methoden im System angepasst werden, damit die Wrapper letztendlich weggelassen werden können, da PEAR UND phplib für mich auf Dauere keinen Sinn machen.
Wrapper würden wir für das Auth, DB und USER brauchen, wobei ich nicht weiß, ob PEAR schon eine Klasse zum Speichern von Uservariablen hat. Weiß da jemand was?
@steff
Liveuser ist schon eine sehr interessante Idee, allerdings werden wir das nicht mehr brauchen, da ich momentan selber ein Gruppen- RechteSystem entwickel, was auch schon sehr gut funktioniert. Was LiveUser fehlt, sind Contenido spezifische Anpassungen. Da eine solche Klasse immer recht allgemein gehalten ist, wird es anfangen zu krachen, wenn versucht wird, gleiche Rechte für verschiedene Clients/ Sprachen und da dann noch spezielle Rechte für einzelne Seiten/ Kategorien anlegen zu wollen.
Ich hatte für ein anderes Projekt mal den PEAR- Cache benutzt, das hat super funktioniert.
Eine Doppelbelegung mit Wrapperklassen würde bei mir so aussehen: Die Klasse hat die gleichen Schnittstellen wie die phplib, damit ist dann der gesamte Unterbau kompatibel.
Nutzt man die phplib, ist der Wrapper unnötig, da sowieso alles über die phplib geregelt wird.
Nutzt man PEAR kommen die Wrapper hinzu.
Für die Version 4.4 con Contenido wäre dies für mich OK, später sollten aber nach und nach alle Methoden im System angepasst werden, damit die Wrapper letztendlich weggelassen werden können, da PEAR UND phplib für mich auf Dauere keinen Sinn machen.
Wrapper würden wir für das Auth, DB und USER brauchen, wobei ich nicht weiß, ob PEAR schon eine Klasse zum Speichern von Uservariablen hat. Weiß da jemand was?
@steff
Liveuser ist schon eine sehr interessante Idee, allerdings werden wir das nicht mehr brauchen, da ich momentan selber ein Gruppen- RechteSystem entwickel, was auch schon sehr gut funktioniert. Was LiveUser fehlt, sind Contenido spezifische Anpassungen. Da eine solche Klasse immer recht allgemein gehalten ist, wird es anfangen zu krachen, wenn versucht wird, gleiche Rechte für verschiedene Clients/ Sprachen und da dann noch spezielle Rechte für einzelne Seiten/ Kategorien anlegen zu wollen.
Ich hatte für ein anderes Projekt mal den PEAR- Cache benutzt, das hat super funktioniert.