“Proper” way to pass session information

  • jlanpheer

    (@jlanpheer)


    7 months ago

    Hello, as an adjunct to an earlier question that i asked just a day or so ago, i wanted to inquire on the “correct” or “WordPress way” to pass session information between pages.

    My use case is this: I am creating a application within a website (through the use of a plugin that i am writing) with its own custom login/password and based on that, i’m assigning that user a role and each role has certain screens that they will have access to. After they’ve logged in, I give them one or more links that allow them to proceed to those other pages. My question revolves around how to pass information from the login page to the other application pages. In each case, i want to pass a userid and the application role that they’ve already been granted.

    My question resolves around “the right way” to do this. One way to do this would be to create a ‘virtual’ form and programmatically ‘save’ the information and pass the data via $_POST. But, is this the “proper WP way” to do this? My first alternative choice to even attempting that was to set a $_SESSION value like this:

    $_SESSION['emp_name'] = $_POST['emp_name'];

    Then, on the target page, i attempt to retrieve that value like this:

    $emp_name = $_SESSION['emp_name'];

    I tried setting the values via setting $_SESSION[‘username’] (for example), but found that this value did not persist between pages. I have also considered/tried cookies. However, i’m not sure this is the ‘right’ use of cookies either, which typically save data over multiple sessions, which i don’t necessarily want. In addition, it’s my understanding that you have to set the cookie value in the ‘init’ action hook and put the code in the functions.php file. During that action, we won’t know the value to set in the cookie.

    In short, i “think” i can fall back on the ‘virtual form’ method and pass the data via POST, but is that the “WordPress Pro” way to do it? I’m looking for pointers/examples on how to do this “the right way”.

    Many thanks for anyone who can take the time to help out.

Viewing 6 replies - 1 through 6 (of 6 total)

  • When you login to WordPress, it sets a session cookie, e.g. wordpress_logged_in_XXXXXXXXXX, and records an active session in wp_usermeta for that user in session_tokens.

    With this, as you move from page to page, WordPress can read the cookie, validate your session, and you can grab user data stored in wp_users and wp_usermeta.

    When you say:

    I am creating a application within a website (through the use of a plugin that i am writing) with its own custom login/password and based on that, i’m assigning that user a role and each role has certain screens that they will have access to.

    Are you saying it’s just a custom form, and you’re using WordPress user accounts and roles behind the scenes, or are you saying you’re authenticating and storing users in something like a custom table?

    However, i’m not sure this is the ‘right’ use of cookies either, which typically save data over multiple sessions, which i don’t necessarily want.

    You’re in control over how long a session lasts. You can set the cookie to expire any time, and you can also kill the session / log the user out at any point in your application.

    In addition, it’s my understanding that you have to set the cookie value in the ‘init’ action hook and put the code in the functions.php file. During that action, we won’t know the value to set in the cookie.

    When a user loads the page with the login form, yes, init will already be too later, but the user hasn’t authenticated yet, so that’s okay.

    When a user submits the login form, it will create a new request, and it’s in that request where you would check to see if the login form was posted, validate the credentials, create a session cookie, and then redirect the user to a page that checks if the user is logged in, and if they are, loads the page.

    Last, if I remember correctly, WordPress does not PHP’s $_SESSION, which would explain why the value doesn’t persist. In fact, I believe if you were to try and start a session, WordPress would advise to not do that, as it can cause confusion and conflicts between how WordPress handles sessions.

    Thread Starter jlanpheer

    (@jlanpheer)

    Hi, and thanks for your reply. I am not using WP user accounts at all. Most users will not have a WP account on the site, so my plugin creates a separate store which stores user names, passwords, roles and a few other key pieces of information. So, once they ‘login’ (not into WP itself, but into this ‘application’), the plugin will determine what they can see and then provides a series of options via links based on their role. The app will then want to pass this information to several other possible pages, based on the permissions that the plugin determines and grants. I’m seeking the best way to do that.

    With regards to WP’s not handling PHP’s $_SESSION variables, yes i have read that also and can confirm that to be the case, which is what led me to this question, i assumed (incorrectly) that i could do that when i started this. So, my search for a solution continues. I was not able to get cookies to do the job, i kept getting ‘headers already sent’ errors. If anyone thinks cookies is the way to go here, could you provide just a bit of sample code and where it might be placed to get me started? Otherwise, it sounds like dummy-ing up a ‘virtual form’ programmatically and sending the information via POST variables might be the way i have to go. I guess that I was thinking that there was a better way?

    Thank you in advance for all opinions! I’m self-taught and ramping up towards ‘pro’. ??

    Reading this, I’m wondering why you’re re-inventing the wheel with a custom authentication system, when WordPress already has the capacity to do everything you want it to do, and it does it securely and reliably?

    What lead you down the custom route vs. just using a custom form to register a WordPress account behind the scenes, and then creating new roles to meet your needs?

    Thread Starter jlanpheer

    (@jlanpheer)

    I appreciate the question, but it is probably too late in the game to change to a different path. This is a custom system that I am building and the people using it do not have WP accounts, and i thought it more secure to do it this way.

    When you say “just using a custom form to register a WordPress account behind the scenes, and then creating new roles to meet your needs”, are you referring to something like this: https://www.youtube.com/watch?v=jbiBJdowxG0

    If so, maybe i can circle back to that, but i’ve got to press ahead with the path that i’m already on for the moment. Unless someone has a better suggestion, sounds like a custom form is the way to go.

    Yes, much like in the video.

    I appreciate the question, but it is probably too late in the game to change to a different path.

    Whenever someone tries to do something that WordPress can already do, I tend to ask this question, because often the reason behind the choice can be solved another, simpler way.

    If, for example, you said: “Well, I don’t want users to register a WordPress account because I don’t want them to see or access the WordPress dashboard.” Then I would provide a solution for that.

    In summary, I think using WordPress would actually be faster and safer, and not just during the development, but also when it comes to future maintenance– a benefit that can be overlooked.

    I leave you with this quote:

    “If you don’t have time to do it right, when will you have time to do it again?”

    John Wooden

    In the end, whichever way you go, you’ll learn something. I only provided this context because I got the sense that you’re interested in finding the “right” way, and while this is only my opinion, based on the limited information here, I think that would be the right way. ??

    Thread Starter jlanpheer

    (@jlanpheer)

    Thank you for your guidance, i appreciate that, i’m learning a ton. Also, i have now seem to have come up with some extra time to implement your “proper” way of doing this, so i AM going to pursue it.

    In your last response, you wrote this: “If, for example, you said: “Well, I don’t want users to register a WordPress account because I don’t want them to see or access the WordPress dashboard.” Then I would provide a solution for that.”

    Initially, that was one of my hangups when considering this approach. Could you point me at any resources that would guide me thru that? Because it is true, i would ideally want to set up the account for them (and it’s not just 1,2 people) and i do not want them to see or access the WP dashboard (which i “think” i can accomplish to restricting permissions on the page?).

    If you have any thoughts on it, i’m going to push ahead on this approach that you recommend.

    thank you VERY much!

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘“Proper” way to pass session information’ is closed to new replies.