Session Management

Gesperrt
JRod
Beiträge: 24
Registriert: Sa 21. Sep 2002, 06:23
Kontaktdaten:

Session Management

Beitrag von JRod » Mo 18. Nov 2002, 10:22

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

Björn
Beiträge: 276
Registriert: Di 17. Sep 2002, 18:25
Kontaktdaten:

Beitrag von Björn » Mo 18. Nov 2002, 15:08

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

JRod
Beiträge: 24
Registriert: Sa 21. Sep 2002, 06:23
Kontaktdaten:

Beitrag von JRod » Mo 18. Nov 2002, 17:15

@björn: danke für die Antwort....
eine Kleinigkeit noch: Welche Version von phplib wird momentan verwendet? und wenn es eine "ältere" ist, wird ein upgrade geplant bzw. ist da schon jemand dran?

Gruß
Jose Rodriguez

Björn
Beiträge: 276
Registriert: Di 17. Sep 2002, 18:25
Kontaktdaten:

Beitrag von Björn » Mo 18. Nov 2002, 19:51

Momentan ist es die 4.2d. Auf längere Sicht ist es geplant, die phplib gegen PEAR auszutauschen und das Sessionmanagment mit internen PHP- Funktionen zu ersetzen. Aber bis dahin wird wohl noch etwas Wasser den Rhein runterfließen.

steff
Beiträge: 31
Registriert: Mo 28. Okt 2002, 12:56
Wohnort: Kölle
Kontaktdaten:

Beitrag von steff » So 24. Nov 2002, 10:09

Es existiert auch eine Wrapper-Variante der Phplib-Klasse session unter dem Namen session4.inc. Damit können die PHP4 eigenen Sessionmethoden über die Phplib-Syntax angesprochen werden.

Steff

Björn
Beiträge: 276
Registriert: Di 17. Sep 2002, 18:25
Kontaktdaten:

Beitrag von Björn » So 24. Nov 2002, 15:00

Ja, genau, siehe Link oben :P

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.

ekke
Beiträge: 130
Registriert: Mi 18. Sep 2002, 18:26

Beitrag von ekke » So 24. Nov 2002, 16:34

@Björn:

meinst Du das?
VIII. 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/packages.auth.php


III. 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.
http://pear.php.net/manual/en/core.db.php

Gruss ekke

Björn
Beiträge: 276
Registriert: Di 17. Sep 2002, 18:25
Kontaktdaten:

Beitrag von Björn » So 24. Nov 2002, 17:33

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. :wink:

Ich denke mit dem Aufkommen des PEAR hat die phplib ausgedient und man sollte sich überlegen, ob es nicht besser ist umzusteigen.

ekke
Beiträge: 130
Registriert: Mi 18. Sep 2002, 18:26

Beitrag von ekke » So 24. Nov 2002, 18:29

viele projekte, die ich verfolge/unterstütze nutzen jetzt pear. habe aber noch wenig erfahrung, wie es auf billig-providern funtioniert. auf den eigenen testservern ist immer alles gut.
Kleiner Aufruf: Wer länger Erfahrung mit pear hat, kann ja diese mitteilen.

Gruss ekke

JRod
Beiträge: 24
Registriert: Sa 21. Sep 2002, 06:23
Kontaktdaten:

Beitrag von JRod » So 24. Nov 2002, 18:59

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

steff
Beiträge: 31
Registriert: Mo 28. Okt 2002, 12:56
Wohnort: Kölle
Kontaktdaten:

Beitrag von steff » Mo 25. Nov 2002, 10:59

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

Björn
Beiträge: 276
Registriert: Di 17. Sep 2002, 18:25
Kontaktdaten:

Beitrag von Björn » Mo 25. Nov 2002, 18:05

@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.

Gesperrt