Topic: [SOLVED] Zend Framework 1.5 accessing Session Namespaces

[lazzerous]

 Zend Framework 1.5 Session Namespaces
Of all the docs I've found (and devoured) on Zend Framework 1.5's Session namespaces, I cannot find anything on how to access a namespace once you're directed to another script.

Example:
in your Auth class, you authenticate the user, start the session, create the namespace, add values to the namespace and then redirect the user to the index page. From the index page, I am trying everything under the sun to access the values I applied to the namespace in the AuthController class and am having no luck

From my auth class:

Code: [Select]

// initiate sessions
require_once 'Zend/Session.php';
Zend_Session::start();
require_once 'Zend/Session/Namespace.php';
           
// processing and validation logic

// namespace assignment
$authNamespace = new Zend_Session_Namespace('Zend_Auth');           
$authNamespace->setExpirationSeconds(720);
$authNamespace->userID = $employeeData->id;
$authNamespace->fName = $employeeData->sFName;
$authNamespace->lName = $employeeData->sLName;
$authNamespace->email = $employeeData->sEmail;
               
$this->_redirect('/');
Once the user is redirected, I am initiating the session within the bootstrap file.
Within my layout file (layout.phtml) I am doing the following with no luck:
From the bootstrap file (index.php):

Code: [Select]

// initiate sessions
require_once 'Zend/Session.php';
Zend_Session::start();

require_once 'Zend/Session/Namespace.php';
$authNamespace = new Zend_Session_Namespace('Zend_Auth');
From layout.phtml (output wrapper for all files, excluding login script)

Code: [Select]

<p id="logged-in">Logged in as <?php echo $this->escape($authNamespace->fName . ' ' . $this->escape($authNamespace->lName));?>.
What am I missing here?

[hitman6003]

Why aren't you using Zend_Auth to get the user's ident?

Code: [Select]

$auth = Zend_Auth::getInstance();
if ($auth::hasIdentity()) {
  print_r($auth::getIdentity());
}

[lazzerous]

The login initially accesses an LDAP server to see if the user exists and the login credentials match.

If everything checks out, separate data is pulled from a MS SQL database on a different server that needs to be populated into the session data.

[lazzerous]

echo-ing out $authNamespace->getIdentity() returns the username used to log into the LDAP server.

the following is the result of a print_r on $authNamespace:

Code: [Select]

Zend_Auth Object
(
    [_storage:protected] => Zend_Auth_Storage_Session Object
        (
            [_session:protected] => Zend_Session_Namespace Object
                (
                    [_namespace:protected] => Zend_Auth
                )

            [_namespace:protected] => Zend_Auth
            [_member:protected] => storage
        )

)


[hitman6003]

Sounds like an extension to Zend_Auth is in order.....

[lazzerous]

Seriously?

Zend would put this session functionality in without being able to access the session properties once you move to a different script?

That would defeat the entire purpose of session variables.

There has to be a simple answer here

[hitman6003]

And what you're doing is defeating the entire concept of abstraction...now where ever you manipulate that data you have to call Zend_Auth, Zend_Session, and whatever code you're using to gather data from the database. 

Why not write a simple Zend_Auth_Adapter that does it for you, once.

[hitman6003]

By extending Zend_Auth_Adapter to be customized you can then return back a Zend_Auth_Result object that has whatever username you want...get if from the database for instance.  Then, when you call Zend_Auth::getIdentity(), it returns the valid username, not the incorrect one.  By breaking the functionality of getIdentity() (by it not returning a valid identity), you make things much more complicated for yourself...and whatever unlucky sap has to fix/extend your stuff in the future.

[lazzerous]

I'm just trying to understand how Zend Framework works

getIdentity does return the log-in username of the current user.
However, that user's details that need to be accessible on any and every page need to be stored as well.
I am able to access the session namespace data that I created within the bootstrap file, just not within the layout.phtml UI wrapper

Let's try this again. What am I doing wrong here?
Do I need to store the secondary values I am pulling after the user is authenticated somewhere other than the session namespaces?

[lazzerous]

Ok - I figured it out.

Lete me start this with my opinion on how Zend handled this. It's absolutely ridiculous. Rather than using $_SESSION variables and organizing your data however you want, Zend wants you to use their syntax to set session variables in separate sub-arrays. Given that, these session variables are NOT available to any/all script in your M/V/C files.

I have been forced to commit those session variables to Zend_Registry values (have to be set for each page load, but are available to all files within your M/V/C framework).

So basically, I now have to initialize the session variables and commit them to Zend_Registry values for EVERY page load via the bootstrap file.

This is retarded.  Absolutely retarded.

I am honestly hoping and wishing that someone can come along and say 'Hey, Zend did this for this and that reason and here's a smorgasbord of benefits from doing so.

It's a great wish, but somehow I doubt anyone will be able to find benefits that outweigh the cons here.

[hitman6003]

using $_SESSION variables and organizing your data however you want

You are using $_SESSION variables, just not directly.  And by using namespaces, you are organizing however you want.

Zend wants you to use their syntax to set session variables in separate sub-arrays

It would defeat the purpose of using Zend_Session if you don't use their class methods to manipulate the session variables.

I have been forced to commit those session variables to Zend_Registry values (have to be set for each page load, but are available to all files within your M/V/C framework).

Using the registry is fairly normal for this.  However, you can also create your own static class to act as a repository for your session namespace(s), which can be summoned from any page.

If you aren't using the registry (which is a static class to store variables), then you are probably creating multiple instances of the same session namespace, which can lead to confusion and the wrong data being stored / retrieved.  Additionally, since locks and such are stored in the instance (not the session variables themselves), if you set a lock in one instance, the other(s) don't know about it and will still modify the value.

So basically, I now have to initialize the session variables and commit them to Zend_Registry values for EVERY page load via the bootstrap file.

Ummm, you have to do with with normal sessions anyway...session_start().  Using Zend_Session you're just using "$session = new Zend_Session_Namespace('yournamespace', true)".

This is retarded.  Absolutely retarded.

I'm sorry you think so. 

Namespacing the session is actually quite good for security purposes.  Probably the most common thing to store in a session is whether a user is authenticated or not....e.g. "$_SESSION['authenticated'] = true".  Well, imagine you have other applications running on your server that require authentication to access.  If they all use the above $_SESSION['authenticated'] to determine if the user should be allowed access, then when the user logs into one, they are logged into them all...even applications that they may not actually have access to (remember session data is separated on the server by domain names...not path to the file requesting session data...so if all of your apps are on www.myserver.com, then they all share a $_SESSION array).

If you are using Zend_Session and creating a namespace for each application, then you don't have to worry about that...

Application1:

Code: [Select]

$session = new Zend_Session_Namespace('application1', true);
if ($session->isAuthenticated == true) {
  ...
}
Application2:

Code: [Select]

$session = new Zend_Session_Namespace('application2', true);
if ($session->isAuthenticated == true) {
  ...
}
This allows you to reuse your authentication methods...you simply pass Zend_Auth the session namespace as it's storage adaptor and it will store the auth data in the namespace.  So now, all of your applications can use the same authentication code, without fear of cross application authentication.

Application1 bootstrap:

Code: [Select]

// create the namespace for this app
$session = new Zend_Session_Namespace('application1', true);

// get our authentication, which is an extension of Zend_Auth
// The intention here is to write a reusable single class to authenticate your users, say against your
// local Active Directory domain, which is then used by all applications...users only have one
// username and password for all applications......
$auth = My_General_Purpose_Code_Library_Authentication::getInstance();

// make this applications auth code use the namespace for this application
// Zend_Auth will, by default, use the Zend_Auth namespace, but this defeats the purpose
// of namespacing to protect against cross application authentication
$auth->setStorage($session);

Application1 Authentication controller:

Code: [Select]

// This isn't a full example of how to use Zend_Auth, but you get the point...
$auth = My_General_Purpose_Code_Library_Authentication::getInstance();

$auth->username = $_POST['username'];
$auth->password = $_POST['password'];

// do authentication, which stores the result in our namespace
$auth->authenticate();
Using the above, you can now check to see if the user is authenticated from any other place in your application

Application1 Someother Controller:

Code: [Select]

// get the auth instance
$auth = My_General_Purpose_Code_Library_Authentication::getInstance();

if (!$auth->hasIdentity()) {
  // user is not authenticated
  $this->_redirect('auth', 'login');
}