Accessing session variables from within Drupal

I'm wondering if anyone has figured this out.

I'd like to create a page in Drupal which gives my members a set of pre-configured affiliate tools, such as emails, articles, reviews, etc. I want my members to be able to copy-n-paste these tools and have their affiliate link automatically inserted.

It seems I would be able to do this using session variables, but when I try it, it doesn't seem like the aMember variables are available within Drupal. However, I have a Drupal page which includes the amember/member.php page in an iframe, and it comes up fine, showing the user as logged in.


Does anyone have a solution for this?

I also need this

I would also like to be able to access the aMember session variables from within Drupal, or at least access info like user subscription date, etc. Any ideas? I tried doing session start, etc. but it doesn't work.

Thanks for the reply Alex. Somehow, I thought that PHP sessions would be the same regardless of the application, and was very confused. I appreciate you clearing it up for me.

For now, I've modified aMember to store basic member data in a cookie, and modified the Drupal [REPTag] module to read the cookie and use it when replacing custom variable tags.

The problem is Drupal logins

The problem is people are logged into aMember and thus have access to the Drupal site but are not logged into Drupal. Might be their Drupal session timed out before aMember or something. If I could at least access the aMember user ID via a cookie or something in Drupal I could have it auto log them in on initial load.

My experience has been the opposite -- Drupal logins last longer than aMember sessions. In fact, Drupal logins are lasting for multiple sessions.

The ideal solution would be for the aMember module for Drupal would modify login/session behavior so the 2 systems were in sync. Personally, I have no idea how this would be done, though.

I have analysed the way Drupal handles sessions. Here is how they work

1. Drupal overrides standard session calls by redirecting it to internal functions.
2. The internal functions are database calls, which essentially rebuild all of the $user data every page load (sloooow).
3. It maintains user sessions by storing the session_id in a cookie, and also in the "sessions" table (database). The table is where the expiry of the cookie is stored.

Because all user information is stored and loaded to/from a php variable $user, the only real way to access this information would be logically, to simply include the Drupal information.

Yet, including the drupal pages, you must initialize the bootstrap, and in doing so, all visibilty of sessions that currently exist from any other app, become inaccessible, as they are redirected to the drupal session handling functions, which of course, don't handle anything non-drupal related.

So for anyone who says they have had an amazing experience with Drupal+aMember with SSO, really needs to re-assess the completeness of the integration on their site if they have not overcome the above problems.

After many hours of laboring, we managed to overcome this burden, however it required core changes in bothe drupal, and aMember in order to handle something as simple as ajax / php communication in a secure manner. There still is no direct communication between Drupal and aMember as Drupal is not friendly for third-party apps. Any problems you face with such an integration are not at the fault of aMember. It is your fault for choosing Drupal over a more friendly system such as Wordpress. (which happens to be only 4 calls in order to have complete SSO with full theme in an aMember+Wordpress combination).

WordPress may be more friendly for newbies, but Drupal is certainly more capable. You don't see any major players like The White House, New York State Senate, or Sony using WordPress, but you do see them using Drupal, which is a testament to the power and flexibility of the platform.

At the moment, I'm using a single installation of Drupal to run about a dozen websites. I don't think WordPress can do that. Also, my members are able to manage their subscriptions without leaving the Drupal framework. I'm currently doing this with iframes, but if I took the time, I could extend the aMember/Drupal integration module to make it seamless. It would really just be a matter of writing a couple of new hook functions to pull/push aMember data at the appropriate times.

I've always been amazed at how easily one Drupal module can modify the way other modules work. There are plenty of hooks available to add whatever functionality is needed. You just have to know enough about the system and programming in general to do it.

Of course, there's the other side of the coin too. UberCart (a Drupal project) is growing in functionality and may eventually be able to take over membership management functions.

I just realized the main source of your problem. You're thinking of the integration between aMember and Drupal backwards. You're thinking that aMember is responsible for serving content to the user from a "Drupal respository", which won't work well, as you've found.

What you should do is think of aMember as a gatekeeper protecting the Drupal content area, and let Drupal handle content delivery, which is where it shines.

In a nutshell,

Integration

Those sites you provided a all pure customizations to Drupal/Joomla only .. no third party scripts. (also against GNU Open Source as the copyright is removed referencing Drupal --- if they in fact ARE said script).

aMember is built to be integerated INTO a system to manage users and payments and products etc. It has an API to "sync" user information, and such with these systems -- also works well.

However -- Drupal / Joomla ... use non-specialized naming for variables and functions, and thereby including a "bootstrap" which loads 500 sub-files (impossible to filter through while maintaining some sort of sanity) -- that initializes AND overrides the session created by aMember (try adding the bootstrap to "footer.html" in /templates/ and see how that flies).

aMember is a nice cleanly written script which allows for customization, and easy integration into most scripts available -- regardless of complexity. I'm sorry, but Drupal/Joomla -- over-rated. Nice you can get great themes and stuff, but it sort of reminds me of IBM vs the Clone. Drupal/Joomla wants Drupal/Joomla to PWN the server -- all else must fit inside. It has a "i do not want to share or play well with others" sort of attitude. If you don't write the program to be Joomla/Drupal specific --- well ... Joomla/Drupal just doesn't like that and will stomp it's virtual feet by pooping all over your screen.

I am saying in my previous post -- that it CAN work ... but it's really a hack, and you are basically bypassing Joomla/Drupal so that you actually CAN fully integrate without re-writing aMember's php files just to adhere to the Joomla/Drupal standards (also not fun, but easier than "fixing" Drupal/Joomla).

(Drupal/Joomla)'s "all your bases are belong to us" attitude is what swayed me away from all those fancy candy-eyed templates. The solution above allows for integration without having to delve into the rabbit-hole deep source tree of Drupal/Joomla.

aMember = Membership/Affiliate/Payment managment and content protection with checks in place to ensure content being delivered has been authorized/paid for.
Drupal/Joomla = Content Management System : Fancy html editor with user management for content editing/contribution -- a blog.