I've been working on an application that requires users to log-in to view their material. Each user has their own subdomain which is locked by it's own accounts database. (I've done it this way for a reason, It's similar to how a forum free-host would work).
My problem is that if a user logs in using their subdomain..
Example -- sub.domain.com
and then moved to
Example -- sub2.domain.com
Everything is fine, they will be required to login again to access sub2.
However, let's say a user goes here to login (The actual directory of the subdomain)
Example -- domain.com/sub/
And then moves to
Example -- domain.com/sub2/
They will still be logged in and have access to all of the users information in sub2
How can I go about setting this up so I wont run into this problem, if anyone is curious I use $_SESSION for this login system.
Based on the comment that GolezTrol provided, I came up with this solution. This solution may have it's problems and if it does I would like to be informed about them. What I did was gave each client it's own Private-Key. (This key is randomly generated when their website is created and stored locally on the clients server. Clients do not have access to the files so this can't be downloaded or modified). I then store the private key in the session, and check the private key that is in the users session versus the private key of the client they are trying to view, if they are not the same it brings the user to the login page and clears their session. (This will log them out of their own dashboard as-well, but I'm planning on making it so the session dies when they leave the page anyway)
The only way someone could edit their session data to get access to another client would be by having the clients private-key, and considering they can't get that without logging in, in the first place, I doubt we have a problem.
Related
I have a problem in my project. When admin is logged in, no front end user can login in the same browser, why this happens? But when I destroy the cookies and then tries to login as user it correctly logs in.
How can I solve this?
Any major browser will only store one session cookie for a site, but the site developer gets to choose what's in that cookie. It seems like your site is storing user information in the session cookie, which is then getting overwritten when the other tab stores different information in the same cookie.
You don't provide much detail about how your specific site operates, but here are a few general ways of approaching this problem.
1) Use different browsers for different users. Different browsers don't share cookies between them. If your goal is simply to test your site with multiple users, this is the way. You can also use Incognito/Private mode to log in a separate user, as this mode doesn't share cookies either.
2) Don't use session cookies to store user information. This is a non-starter on most websites, but if this is an internal site or strictly controlled environment, you may be able to pass user identification via the URL, POST data, or some other hidden identifier in the request.
3) Store data in the session cookie for all currently logged in users. Depending on the web framework, it may be possible to create a map of user -> cookieData and look up the correct one based on which user is making the request. This is an advanced technique, and I don't actually know if Laravel exposes this level of control.
Harshad is covering all the aspects very well, but I can tell about a little trick a I have used when I wanted to test using different user rights (same browser). In my case, it was Windows Authentication, but it does not matter:
1) define a flag at user level (e.g. SuperUser). It can be 0 (false) or 1 (true).
2) allow "impersonation" - if an administrator has SuperUser flag set, he/she can change its roles/rights and see the site as if he/she is a normal user with that particular rights, but user management section is still accessible, to allow changing rights back.
3) Little changes are required in the user management section to allow SuperUser security implementation (i.e. section is showing if user does not have admin role, but it is marked as SuperUser)
So, you are testing as a single user, no multiple session cookies or other tricks are required. You can have one tab opened with your user profile and other(s) to do the actual testing.
Note: regarding the multiple browser suggestion, it is a quick solution for developers, but in corporate environment, this can be a real problem, as users (e.g. key users that have to test security) do not have access to more than one browser.
I am developing an application in which security plays main role. When I am trying to login with username and password, other login on any other system with same username should be deactivated.
How can I do this? When I google this issue I am not getting any related ideas.
I logged in from my home and when I login to my system from office my
personal system session should be destroyed
In terms of specifically "personal session being destroyed" would mean remotely clearing your home browser history (to delete sessions/cookies etc).
Which is possibly not necessary (depending on security level you need), or better to just have remote access to your PC.
A solution if you do not actually need to destroy "home" sessions.
A basic method would be something like:
Upon successful login, script sets a local session ID and stores it in the DB.
Each page/section within the secure area checks your local session ID with the one in the DB.
If match, you are shown the page, otherwise redirected to the login page.
Every time you successfully login, it resets the session stores in the DB, so when logging in at work you would not be logged in at home as sessions no longer match.
Your Scenario
You login in at home, a session is created and the session ID is stored in the database and referenced in your local browser (cookie by default).
Each secure area page will check if the users local session ID matches the one in the database.
At home, currently, it does.
You go to work, go to login page (which finds no session/cookie so allows you to try to login).
When you login successfully, the script will set a new session and session ID, update the database with that new session ID.
Now when you browse the secure area at work the scripts check your local session ID and database and they match up, so can see the secure stuffs.
At home, someone tries to browse your logged in area and the local session ID no longer matches the one stored in DB, as it's now the session ID you set from logging in at work.
So they are redirected to login page.
Security Note
This is just a basic example, and while the above will work, it is not a perfectly secure "login system" in itself. Best practice of having a secure login system is already covered in many other questions/answers/tutorials (ie using HTTPS, IP log, browser data check, timestamp + auto logout, etc).
I have a website with a PHPBB 3 forum. The website's authentication mechanism is based on PHPBB. I have migrated the site to a new dedicated server where I created an ubuntu VM on HyperV. When I try logging in to the new site, multiple cookies of the same name are set. These are the auto login (k), user (u) and session ID (sid) cookies. Only 1 set of these cookies tell us that the user was authenticated. I have attached two screenshots of the response headers (one from the old host & one from the new one).
Is there a PHP setting I can toggle to prevent this? The PHP files and database are identical between the two hosts. I tried fiddling with the PHP cookie name setting in the config table, clearing caches & session tables. But nothing seems to help.
Strangely though, if I manually add the sid as query string to the web page, I am shown as being logged in.
New Site
Old Site
It looks like the cookie path is set right... Are you, or a select few, the only ones with this problem? IF so, I would first try to clear all those cookies from the browser and start over. I've solved many a cookie problem with phpBB like that. A second option is to go into the admin panel and change the cookie name. That will invalidate all login cookies and kick everyone off the board... but they should be able to log in afterward.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to create a cross domain sign in just like Google. So you have the same account for your youtube, gmail, google+, etc. However, there are several questions I'm confusing about:
Suppose I have 5 websites, I don't want to transfer any data about the user besides his/her email, username and password. If I have only 1 user database instead of 5, every time I call the user database to access user's profile picture, username and etc, do I need to call the remote database?
I've been thinking about having a remote user and session database so every child site access that instead of local user and session database. But my application uses the table extensively and i'm worried about the performance of getting the data from a remote database every time.
How can I implement this in a clean way so every child site can easily access the user info locally, and they also share the same login/logout process just like Google and its products? (I'm using a PHP framework called Yii with MySQL)
I've come up with the following solution and I posted it as an answer as well, please advice if there is any issue about this? Thank you guys for help.
Have a user table in every child site, say child1.com & child2.com
Have a super user table in the parent site, say parent.com
When user logs into child1.com, check identity, redirect to parent.com/child1 to register or login. Once it's done, redirect back to child1 with an encrypted URL to login the user automatically. If the user's info has changed from the parent database, we can sync it here to the child database, (If it's a register process instead of a login process, write the user_id, username and email as well into the database so you can access this locally from child1.com)
When user logs into child2.com, it redirects to parent.com/child2, however, the users has been authenticated to parent1.com, so it redirects the user to child2 with out encrypted URL, so child2.com logs the user in directly.
For logout process, logout child1.com & curl other encrypted logout link to logout this user from other sites say child2.com or parent.com
After talking to a bunch of people, the following way seems promising.
Have a user table in every child site, say child1.com & child2.com
Have a super user table in the parent site, say parent.com
When user tries to log into child1.com, redirect to parent.com/child1 to register or login. Once it's done, redirect back to child1 with an encrypted URL to login the user automatically. If the user's info has changed from the parent database, we can sync it here to the child database, (If it's a register process instead of a login process, write the user_id, username and email into the database so you can access this locally from child1.com)
When user logs into child2.com, it redirects to parent.com/child2, however, the users has been authenticated to parent1.com, so it redirects the user to child2 without login again, and child2.com logs the user in directly with the encrypted URL from parent.com.
For logout process, say the user logout from child1.com, we curl other encrypted logout links automatically to logout this user from other sites say child2.com or parent.com
You can edit UserIdentity class ,find it in components folder, in each website and override authenticate() method to check OAuth, remote database, web service or what ever method you think it is comfortable for You... Don't worry about performance, because login is performed only once per session...
Why not create something like this?
MasterSite.com
users
id
user_email
password
sites
name
domain
salt
site_users
id
user_id
site_id
Child1.com
Say the user's name is Joe and has visits www.child1.com. He clicks on www.child1.com/register/. He will be redirected to www.mastersite.com/register/site/child1. After the registration he will be redirected back to www.child1.com/session_id/abcdefgh12345
Now say the user visits www.child2.com. And he visits www.child2.com/login/. The sysem will redirect him or popup a login back from www.mastersite.com/login/. If a session id already exists on www.mastersite.com then the user will be simply redirected back to www.child2.com/session_id/abcdefgh12345
That session id will be stored in the MasterSite.com's database and occasionally will be updated by www.childX.com as needed.
Storing user's data on each website is ok to a certain extent but it can get ugly real quick. However, since there are cloud based solutions nowadays... I don't think it will be much of a problem to scale the MasterSite's database or CPU power if the need arises.
Having a single remote database (parent server) with user information sounds like the simplest solution.
Keep in mind that PHP sessions are stored on a server's local file system, by default. So when you log into website-B with website-B's session data, you are not logged into any other sites.
This is where the magic happens. You need to instruct PHP to use the remote MySQL database to store session data, instead of the local machine's file system. Once set up, this works like magic.
I did a quick google, and found this site with instructions for setting up a MySQL session table for PHP.
enter link description here
I have developed a web application in PHP for a client. The client is now renting out access to the system to another company on a per user basis.
Is there a way to prevent the secondary company to use a single login and give it to 20 people to use at the same time? I know one can get the IP address of the client machine that is being logged in from, but this is obviously not very reliable method. The answer probably lies in a combination of cookies and tracking things in a database, but my brain gets a bit stuck thinking on how to implement a strategy here.
Create a unique session ID when a user logs in and store that in the DB. Add something to the session authentication code (run on all page visits) that checks that the user's session ID is equal to the one in the DB and if not, log them out. Then your web app will be accessible by only one user at a time.
To be completely honest though, can't you raise this issue with your client?
No way to tell if the login is shared among 20 people. You can restrict access by blocking simultaneous usage thru session cookies.
Most of all, protect yourself with a published Terms and Conditions document. Violation of which - revokes any standing agreement/contract. And sue them if you can provide evidence (logs) that they violated it.
Make sure you bind one user to one session. In that way you can generate a warning screen if somebody uses the same login with another session. You can then let the user choose to close the other session.
In that way you can make sure two users are not using the system at the same time. It's a bit like a software program you have installed on a computer: multiple users can use it, but only one at a time. This is probably fine.
If you don't want that, you should try to bind the login more firmly to the user: make sure he logs in with a personal e-mail address, and he gets notifications (if applicable) via e-mail. Also let the user set personal configurations. In that way you create extra value for users to have their own account.
If you have a login you have authentication, and you write any user id in session, make sure that only one session with this id created, if the session already exists throw error message.
The only problem you will have in case and user did not logout properly, instead of it pressing x button on browser then he will not be able to login till session s not expired.