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.
Related
I have a server with PHP and MySQL. I want to have a login screen where users can enter their email, etc. and then browse my site. What is the best way to keep the user logged in? Ie. they don't have to log in to each page. I have looked into using cookies, and recording their IP address, but I wasn't sure which was best, or if there was a better way?
You can create a cookie based session, whenever the user enters the credentials. The subsequent requests will be having the cookie in the request header, which can be used to identify the user.
link for reference - http://www.opensourceforu.com/2008/12/session-management-using-php-part-1-cookie-based-sessions/
So I have the example-google.php script working, after loging in it throws the default user string has logged in. But my question is how does this protect anything?
Lets say I have //127.0.0.1/example-google.php and I added a href to //127.0.0.1/abc.php after the login is successful.
Well what keeps someone from just typing 127.0.0.1/abc.php? granted I could use $_SESSION to verify that "someone" logged in. But is that going to be enough? Is there a way to re-verify that the user that is trying to access abc.php is truely logged in when thrown from the other page?
Generally, the idea is that you use the session store, indeed.
For example, in my site I have a OpenID login using Steam Community. When a user logs in, after the mode / validate checks etc. from the LightOpenID example, I save their unique identifier in the session store (in this case a SteamID, in your case an email address presumably), then can just use this freely for subsequent requests.
As the session store is server-side, a user cannot impersonate another one without gaining their session cookie (session hijacking is another topic that someone else can go into much more detail on, but I'll give it a shot if requested), but most attacks will be defeated by also storing and validating the requesting IP address.
I keep a couple of mysql tables (one for sessions and one for user information) and store session information in the session table and include a reference to the users table. When a user successfully logs in with their OID provider they are sent back to my site with the confirmation from the provider. I keep track of my user from then on via their session id.
I wipe the session if they choose to log out, but maintain the user info for comments/posts on the site to track who said what.
I actually put a link to "?login={service}" which sends the request to the OID provider and redirects back to that page and on return from the provider it takes the successful login and stores the appropriate information and redirects the user back to the original page where they clicked the "login" button for whichever {service}. You only display the "members only" content if they are verified via OID. You don't create a standard HTML page at abc.php without any sort of way to confirm ID and I think the header redirect is important because it cleans up the URL displayed in the address.
I have a website which has a login/logout feature. How can I ensure, 100%, also in a stable technique, that a user won't be a able to login to the same account from two different computers?
Javascript can't be used for this, since it's easy to disable it.
For example, .NET has a Session_End function that executes when a user aborts the connection with the server. How that can be done with PHP?
Thanks, Guy
Note: This technique would effectively logout the account on the first computer when logging in on a 2nd.
When a user logs in, log the session id for the user to the database or equivalent. On each page request, ensure the session id of the user matches the session id stored in the store for their account. Requests from a logged in account with a mismatched session id should be rejected and the user should be logged out.
It depends on how in depth you want to go. Most commonly:
Create a unique session id cookie on login and saved it in the database
All web pages check the session cookie to make sure it's valid
if the session isn't valid, the user is redirected to the login page
When another user tries to log in, it overwrites the previous session
This essentially kicks out the first user
Large companies will also store the IP address in the database as well (so session cookies can't be stolen)
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.
I want to allow users to use only one system to login.
if they use another machine then they should not be able to login.
If they want to login then they can click request login option which will sent a reset link to the users email which when clicked will reset and update the database so that from now on he can login form that machine form which he made the reset request.
so, when ever the user changes his machine he should not be able to login and can request a reset option.
i am using ip and session id and previous session id to check login from one machine.
if his session expires in that machine he will be logged in next time by storing the previous session id reference in a cookie.
so each time he access there will be two cookies to mean that whether he previously logged in this machine and if so then the session id is updated and he is logged in.
so if he is login in from a machine and if there is no previous/current session-id/ip-address then he is considered totally new to that machine and he cannot login.
Hope i have made it clear. if it is not much clear then please comment then i will edit my question.
I want a better approach or some other efficient mechanism to implement such functionality.
Even if the client is in a lan all the above conditions apply.
do my way of doing this has complications? if so then please suggest a good one.
Thank you.
Editing after a comment from https://stackoverflow.com/users/164394/purplepilot
the user can login anywhere but if the machine changes they can request an reset through their email. when they click the link in the email then that machines ip will be recorded and the user will have to continue in that system. This was requested by the admin cause there is going to be only two admin users.
Why dont you use cookie instead of session as your app demand that.
i think you are confused
Session never stored in client , cookie does. so you have to think about cookie for this app. Logic for the project seems okey once you implement cookie instead of session.