Is it possible to have the same session be active across multiple open windows in a php app?
I want to have SOME of the convenience of the dreaded "remember me" checkbox type system without the same amount of risk to the user's data.
The specific use case I have run into is this: When a user receives a "friend request", an e-mail is sent to them with a link that contains a random hash and their username in the url. Say the person is already logged in to my service in one window and is checking their mail for the confirmation e-mail in another. They click the link in the confirmation e-mail and it launches a third window which initiates a GET request to the relevant confirmation page. I'd like to make it so that if the user is already logged in to the service in another window and the hash and username match those stored in the "requests" table of my database, clicking the link instantly confirms the friend. However, if they are not already logged in in another window, they are then forced to log in to confirm the friend request.
Currently if a person is logged in in another window, clicking the link launches a third window and the person must log in again regardless of whether they have another open session.
Is this functionality possible without using cookies to maintain a persistent login?
Update: This question demonstrates my own lack of understanding regarding how sessions work. The user's session IS normally preserved across concurrently open browser windows by default. The issue, as was addressed in the answer I accepted was that I had one window open with www.example.com as the URL and one with example.com as the URL, in which case a different session is created in the second window rather than continuing the session started in the first window.
If you use cookie-based sessions, the session is already maintained between windows (of the same browser executable).
The session ID is the only client-side stored token in this case, and browsers don't generally segregate cookies between different windows.
You may have an issue in that they're visiting your web site via two different domain names (www.example.com vs example.com vs www.example.org, or the like), but fundamentally there is no problem unless you try to use GET-passed session IDs.
You will technically "use cookies" - but the cookies only hold the session ID, not the session contents. If that is anathema to you, you could store the session ID using the HTML5 LocalData API, or with a Flash object, or a Java applet, or whatever...
I strongly advise against attempting to identify the clients a posteriori via their IP address or browser characteristics. Just have them store a token, and use that to determine who they are.
A typical login system has sessions and cookies . Cookies are only set if the users wants to be remembered to avoid input hes data again from that spesific browser and nothing else.
Session live while you are loggen but the will be destroyde after you close the window thus prompting for a login again.
While saving cookies to a users browser it is vital that you encrypte their data .also instead of the password save a cookie with a refrensnumber (ID) and not their password.
Related
I'm building a PHP webpage which has a Button to download an image. I want to restrict unsigned user to download this image 3 times only.
I don't want to use neither Session nor Cookies because the user can delete his cookies!
I want to use IP, so I used the $_SERVER global variable but the problem here is the IP Address is changeable. It's dynamic and change every period of time.
So What should I do?
Not all IPs are dynamic, this depends on the ISP. Your problem is identifying the user uniquely, which is impossible to do without requiring users to log in. No matter what you use, IPs, cookies, sessions, client side scripts to do browser fingerprinting or store tokens in the localStorage, a skilled used will always manage to get over your protections.
You can only make it difficult for the users:
run a client side script to create browser finger print - https://github.com/Valve/fingerprintjs2 - and send it to the server to help you identify the user
generate a server-side token and send it to the client and store it in the localStorage and send it back to the server
store the IP of the user in the DB
use session / cookies to add an extra layer of security
use an hidden iframe to load code from a different domain you own and add extra cookies from there (sometimes users don't delete all the cookies, just those for your site)
put captchas before the user can download an image so that you're not scrapped by bots
Using a combination of all the above will make it annoying for an user to download pictures from your site without creating an user account, but not impossible.
I am building a website and I am using sessions to check user login. I am wondering if there is any better and safer way to check user login. Because sessions are stored in the clients computer I think they are not very safe and easy to hack. Am I correct?How do big websites like facebook and twitter check if their user is logged in or not. I am new to PHP so dont say my question is too basic.
Sessions are not stored in the client's computer. You must be confused with cookies !
Sessions are definitely the way to go here.
No matter what you use as authentication, if the client computer is compromised, the client's method of authentication can be abused. So in this regard, any other way can only be as safe as sessions are.
All big sites use sessions, usually in conjunction with cookies.
I want you to first understand that Sessions are the only way you can identify a client.
You don't store sessions on either the client or server side. (If you want a secure system.)
First you need to understand the need for sessions, only then you can know what sessions are.
The internet is a stateless network of machines, each with their own identifiers. Most of the communication that we do while sending a request to load a page or visit various links are over the HTTP (Hyper Text Transfer Protocol).
HTTP is a stateless protocol, meaning any communication over this protocol is not required by the protocol to be stored on either the server or client.
Let us understand what this would mean, with an example:
Suppose you try to login to http://example.com
You fill the form, hit the send button.
All the data in your form is then sent to the server.
The server checks if the username and password received was right. If right, it sends you the secure data.
In your next call to the web server, you expect to be logged in. BUT, due to the stateless nature of HTTP, your server does not recognize you anymore.
You can make this work by sending your username and password with every call, but that would mean having to enter it every-time for each request.
Here comes the role of cookies, you set the username cookie as Joe and password cookie as qwerty. Now everytime a request is sent the cookies are sent by the browser and you are happy.
This scenario now again has a problem that you need to make an authentication check everytime on your server thus increasing the load on it.
Enter Sessions. Sessions mean states with some context. It may be a logged in user, it may contain preferences you have set or any other similar stuff.
Here, when the user is logged in the first time, the server generates a session ID. This session ID is then stored by the server in a DB, File or it's Memory (RAM) along with any other data like username of the person who is logged in, preferences etc.
The server response then contains the session ID, which may be in the form of a cookie, HTML5 session states or sometimes even hidden fields.
Now, every call the client makes, contains the session ID. The server then checks its session store for any valid sessions with the same ID and get into context therby giving a pseudo state-like mechanism to communications taking place over HTTP.
How long your browser stores this cookie can also be determined by the server while sending the cookie.
There are advanced techniques for further security like changing the session ID each time a call is made, but lets get into that only if you want me to.
Cheers! :)
In my login code on my website, if the password & username are correct, I set a cookie to keep the user logged in.
I just heard from a user that he doesn't accept cookies automatically through his browser, and that that prevents him from logging in. That rhe cookie is not set.
Is there an easy way to counter that?
Tell me if you need the code I use.
It is possible to get this to work but often a real pain if you're using complex javascript/ajax.
In short, instead of storing the session id in a cookie, you embed it at the end of every link.
so
http://example.com/somepage.php
becomes
http://example.com/somepage.php?SessionId=ABC123
Unfortunately, while PHP can do this for you in some cases, it doesn't help with links you build yourself in javascript - and it only takes clicking a single link without the id to effectively log the user out
See this page for more information
As mentioned by Quentin in the comments, if you're not using a cookie to identify the browser which created the session, it's possible that sharing a link would share the session. This could be mitigated but not prevented by checking IP address/user agent but this would likely fail in large corporate environments with NAT and standard browsers
I recently simulated multiple login in PHP using 1 account. Here's what I did
opened 2 login screens
logged into account 1 using the first login screen
login successful
logged into account 2 using the second login screen
What I want to do is to logout user 1 when user 2 logs in on the same machine and the same browser.
How do I do that? I also did this with Gmail and if email 1 is logged in and email 2 logs in, Gmail displays an alert box saying that user 1 is logged out (assuming that I log in using the same machine and in the same browser).
If you set the same cookie for all users, you can use javascript to periodically check that the username/data associated with that cookie is the same one as originally logged into the page.
If you see a change, pop up the notice and navigate away from the page.
Additionally, if you absolutely have to validate this, you might send the intended user with each post/get request, in addition to the cookie, then validate that the cookie matches that user. This causes other kinds of problems though, so it's probably overkill.
If you are saving sessions (which you should if there's any persisting data involved) just check if the other user session exists and delete it.
UPDATE:
I don't think that's the Gmail approach, at least it's not working the same for me. I can open up 2 Gmail login tabs (same browser, same session as stated) and authenticate in both of them without problems. Certainly both connections appear in Gmail's account activity, but it's not seen as malicious activity, you will only be kicked out if you're on a different computer.
You can't really distinguish between users using the same browser and the same session, just because you're not using a persistent connection, that's the nature of the web.
You need something to distinguish between them: date, browser session, ip, anything. It seems that the only choice you have is using a timestamp when any of them logged in, but that's pretty tricky and i don't recommend it.
I will suggest USER 1 to smack USER 2 if he's trying to use the same login on the same browser (ok, bad joke).
Problem: A download link should be displayed in a user's home page.
That download link should ONLY be accessible if the user logged in.
But the real problem is that the user's home page and the download link are on separate web servers.
Is there a way I can send a token with the download link and validate it there?
users server = serverA.com
your server = serverB.org
if i understand it right, the problem is, that the user is only logged in on server A, but not on server B, and there's no way to share the session state (e.g. session handling over a database)?
from the top of my head, i can think of one option:
server B simply asks server A
means: link on serverA contains the users session id*. serverB then asks server A if the session is valid.
you can't do it without communication between those two servers.
* note: instead of the session-id it would be better to use a random token. session ids should not be private.
that won't stop your users to share the url, so if they want someone else to download the file, they can simply pass the url around. on the other hand, a malicious user could also do this with his session-id.
You could make the download link submit a form with the user info to the target server. There are security implications in doing that, because the login info would appear in the source of the page as values for hidden form fields, so perhaps that not the way you'd like to go.
A second option would be to store the session info in a database, and then simply pass the session key to the new server. This would require the second server be able to contact the first server's database and run a query on it. Setting up a username with permissions to login from that server for read access should be sufficient to do that without opening many security holes.
Finally, you could set up a web service on the first server that would return a yes/no answer when given a username, verifying the logged in status of the user. The receiving link on the second server would then take the username and verify the logged in status before building the response.
If the user clicks the link, he is going from his server to your server.
And if he is logged in on your server, then you can do whatever checks you need since he is trying to access the file on your server. Even though the link is displayed on some other server.
That is if you are using sessions to keep the user logged in, it should be enough in the download code to start the session with session_start() and the user should get logged in session he has already.