I logged into an online forum created by using PHP and was browsing some topics in the web site.
Since the weather was hot, I got to have a bath and left my computer idle for a short while. When I came back to my computer, I pressed a "Add Post" icon.
But When I pressed to submit the new topic,the web site redirected me to the Log in page, I gussed my cookie might have been expired. And then after I logged into the web site again, my new post was created. I am wondering how they do this. What is the method and technique they used?
Did they store my new post to a new cookie or session first when they found that my cookie was expired?
You could do that by storing the post's content into a cookie and once you log the user in, check the cookies that you have set. If you have a cookie set with the content you would create a post with, create the post and remove the cookie. This should work with sessions as well. All depends on how you set your login system.
Related
I'm having an issue with CSRF tokens on externally linked pages.
I have a chat bot in whatsapp that sends a user a one-time link to the site. They click the link and need to enter a PIN on the site in order to confirm a request (we do this so the user's PIN is never saved in plain text on whatsapp).
Like all forms on the site, the PIN page has a hidden CSRF token that gets submitted too. The CSRF token is generated in part with the session id, and on submission part of the validation is checking its for the current session.
I am seeing an issue where on some submissions of the PIN page that the CSRF validation is failing due to the session id being different from the initial page load request.
My guess on what is happening is that the user has an active session with the site already (lets call that session 001). They later get sent the whatsapp link which they click on. It looks like sometimes the browser does not send the existing session cookie (I assume due to some tightening on the SameSite policy stuff), so when the user lands on the PIN page the site sees it as a new visit and creates a new session 002. Then on submit of the form the browser sends the original "session 001" cookie. So the token CSRF token was generated with "session 002", but validated against session 002.
(It's probably worth noting this is a legacy system and no SameSite policy is being explicity set)
I don't want to be logging session ids in production so I can't think of a way to verify this is actually what is happening. I haven't been able replicate this behaviour in my dev environment yet.
Does this sound like a known thing that I am just not understanding well? Any ideas on ways to work around this issue?
Sessions don't work between browser tab reloads as a conceptual model (IMO) https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage. In your use-case, a session is between browser tab reloads (both by refresh, hard refresh or navigation by external link) barring reloads by 'back' button presses. So in short, you need your own session UUID generator and management. Try using UUID classes implemented in most web-server platforms.
localhost may work differently due to http stipulations, although I can't figure out why this wouldn't be reproducible in localhost.
I'm working on a community networking site where users session never expires (unless log out button is pressed). Along with that I've wordpress cms integrated for blogging hosted in sub domain.. I use js to trigger login and logout on wordpress site.. Means when users login to main (non- wordpress) site, they are also automatically logged in to wordpress site.. Here now the problem is, after certain period of time or when browser is closed, the wordpress site automatically logged out from the system-leaving only main website in session, and that will need users to logged out from main website and again re-login just to trigger back the wordpress login...
I'd just want wordpress to never automatically (even if the windows is closed) logout unless logout button is pressed.. I used the following function which doesn't seems to work..
function change_wp_cookie_logout( $expirein )
{ return 1555200; // 6 months in seconds
}
add_filter( 'auth_cookie_expiration', 'change_wp_cookie_logout' );
I've tried with different similar tactics but doesn't get it working..
Thanks in advance
I'd recommend you to check about cookies, in my humble opinion that would be the best approach to persists the user data for a long term. You could use the cookies to restore their data in a new session using some key information. Basically, whenever they close the browser the session will expire (disconnected by the server), but if you have cookies on their end, you could check in server side when a new session is requrested if does it exist a cookie and based on the info you had store there, you can restore the info necessary on their web session.
You can read more about on oficial page:
https://en.support.wordpress.com/cookies/
I have a url shortener that I created to track incoming links. Currently the php sets a cookie and inserts visitor information into the database. It attaches an id to the redirect url and redirects the user to the website.
The website has javascript on the page that takes the id and tries to set a cookie on the front end. If cookies are disabled, the javascript attempts other things to store that id. The reason I am setting the id is due to the javascript sending random pieces of information to the backend.
Is there a way for php to have a fallback if the person doesn't have cookies enabled? I don't want to create a new database entry for someone who visits the same link multiple times who doesn't have cookies enabled. Don't want to be tracking the same person as 2 or more people.
Edit
If I can't prompt the user that their cookies are disabled, are there any alternatives?
2nd Edit
One of the comments brought this up, so I thought I'd post the link here: User recognition without cookies or local storage
I have a page tab app that is a contest with a like gate.
A user likes a page, provides their email address and hits submit to enter the contest.
After they enter, I set a session variable $_SESSION['entered'] = '1'; or something similar
Once they enter, I show more information on the page(html) and remove the email form.
PROBLEM: If the users stays on the page, refreshes it a million times (in the same browser window), the session variable stays and I'm able to tell that the user has entered and display the correct info.
If the user closes the window, comes back later in a new window, etc. I lose the session information and the user is presented with the enter form again (although they've already entered the contest)
How do I sustain the session for the user in the page app if they leave and come back?
You could use a cookie instead. Sessions will close out on exiting the browser, but cookies will last until the expiration date is reached on them.
You could also set it up that they have to log in, and in their user, you set whether they have entered the contest or not and adjust the page accordingly. (just an idea...)
Sessions are destroyed by the browser when closed - nothing code wise will change how browsers handle that. You can try a cookie instead, or try to save the session to their IP/useragent (wouldn't recommend for security though) and reestablish it when they come back.
As written by others Sessions are destroyed if a user closes the browser. i won`t use cookies on your side either. I suggest you to get the users uid and check your database if the user has already entered the form and display the correct page after you have this info.
This might be a more secure and consistent way than sessions or cookies.
Greets
I'm in the process of setting up various authentication methods on a project I'm working on, and the common OAuth 2.0 framework that Google and Facebook use seems pretty awesome. Reading the example Facebook gave though, I stumbled across something that seemed strange to me.
If you look at the bottom of that facebook page, you can see an example in PHP. In their process, they first set a random string to $_SESSION['state'], then redirect the user to the facebook authentication page, which then sends the user back to the original page, where they compare the state string to what's supposedly stored in the session variable. Maybe I'm missing something here, but don't you lose all session data if the user leaves your site? How does this work? How is your session data maintained even though you leave the site?
The session data stays until you close the browser or logout from your app. The session state could be getting saved on the server or on the browser in a cookie. Either way, the session data is available to you once facebook redirects back to your site.
You don't lose your session data, when user leaves your site.
So, we check state value after user is redirected back to our website from facebook.