I have moodle LMS in three different countries (Ex:India, America, Eurppe). For these sites they have individual administrators. Suppose I am the main Administrator, I want to be able to manage all websites with one login.
If I login in Indian LMS and select America LMS in DROP DOWN, then the session should transfer to America LMS. Is there any solution for this?
If your sites are subdomains of the same domain you should consider reading this:
PHP Sessions across sub domains
To set cookie for the main domain and all subdomain. So you can read the same cookie from us.foo.com and also from eu.foo.com
Plus you should have a unique user database or more than one syncronized (i'd prefer the first option anyway).
You're going to encounter cookie domain restrictions as your first major barrier. Essentially, you can't read a login cookie (which are required for sessions to work) from a domain other than the domain that issued it, so a moodle instance at us-foo.com will never be able to read a login cookie from eu-bar.com.
The simplest way to route around this would be to use a separate login form. On submission, use JavaScript to open hidden iFrames to the login pages of all three sites, with the username and passwords passed via GET parameters. Moodle may not natively support login credentials being sent with GET; you may need to edit the login scripts.
There's a forum thread about doing just this with Moodle, though - you may be in luck.
But in any case, for a login multiplexing hack like this to work it will mean you have to keep the admin username and password constant between your three sites. You could enforce this in the database using triggers, if they're all run from the same database; otherwise you'll want to alter the password changing script to write those changes to the remote databases.
Is this a serious undertaking? Kind of. Unfortunately, it's not a very robust solution, and it is likely to be extraordinarily fragile when it comes to updates and the like. You may find that the best choice is to just login separately, particularly given that these hacks don't easily lend themselves to being embedded in the main login for the sites, and you'll need to use similar ad-hoc synchronization to make logging out take place across the network as well.
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.
We are currently using a custom login system that sets a hash in the database on one site, and then when the user transfers between domain and sub-domains it logs them in. It doesn't always log the user in so they click on on the login link/button and it takes them to the login and if they have a session it loads it otherwise it shows the login page.
We would like to get away from that and use something better. With php there is session_set_cookie_params and we were wondering is this secure?
session_set_cookie_params(3600, "/", ".example.com");
If this isn't a good way to use a session across multiple domains what is a better one?
We also have a few subdomains that use their own login system where the same user has a different username/password on that system, will this/that be a problem? We feel that it could be possible that two different people could have the same session id logging two different people on to the same account, since they manage their own sessions.
It is a fine approach, however you have to consider that, if all domains/subdomains you want involved in the same session are not on same server or reside within different applications, that you need to provide some common backend session-storage mechanism that all applications can access for session data.
As far as dealing with multiple logins, you would likely need a logical way to link the logins together so that you can understand that a valid session under one login could be transferred to another login on a different domain. This is really your largest security concern, and one that should likely be addressed by implementing a single sign-in mechanism.
I need to implement a solution for one of my project, where I have multiple domains + multiple sub-domains and they all need to share the same session. All domains and sub-domains would be pointed to the single application which is connected to the single database.
Means if user logged in from any of the domain will be able to visit secure pages of other domains of the application. User may change domain via following a link or via opening a new tab in the browser.
I have gone through some articles and found some below mentioned solutions:-
Session in Database - What if other user from same network with same user agent hits?
iFrame message passing - I heard at somewhere, that iFrame renders on document load and, then checking session after showing some page content will annoy the user.
CURL request with CURLOPT_COOKIEFILE & CURLOPT_COOKIEJAR - I have played with this and it is working fine, but don't know if it is secure and not performance killer.
Single Sign On (SSO) - I need some R&D to implement this and it would be the last option.
Please suggest what to do?
Just to verify I am not wrong, you need to share user session across all your applications.
As rightly said above, you may use 4 of the options above. However, I would like to focus on first option which is putting session in DB and would like to suggest another option as keeping sessions in shared directory or server.
Sessions in DB - The answer to your question (What if other user from same network with same user agent hits?) is you will have different session id's value to uniquely identify each row in Table. So, no need to worry about it. But the disadvantage is, each time DB connection would be required and a query would be fired, when session is initialized i.e. for every single page.
Sessions in shared directory/server - Configure all your applications in a such a manner that all applications store session at shared location. Shared location can either be a directory or a secured server. This can easily achieved by using session_set_save_handler.
I'm currently trying to join 2 web apps on different domains example1.com and ex.example2.net so that you can login to example1 and click on a link to example2 and be instantly signed in, as it would be more convenient for customers to just login the once and navigate between the sites.
I've researched various means ie. php sessions, openID, JOSSO and Kerberos, but what would be a secure and easy way to implement this?
Kerbros is very extensive and for systems requiring high security. Its very difficult to work with, and even just setup over all, I would not suggest this route unless you know linux very well, and provided your hosting provider allows you that type of access over the machine.
Im not familiar enough with JOSSO or openID to comment well on those however.
Any php sessions are only good for the domain, and server the domain is on, kind of like cookies but not, though in all you would use them.
I think your easiest solution more so if the 2 sites are on the same hosting account/server. Is to have a database specific to this cause. What you would do is create a login system like you would normally but instead you would have 2 sites reading off this login. Aside from the normal login you would also have a session tracking table. Typically you already set sessions when users login to keep them logged in, and you'd do the same here, but you'd add a cookie into the equation one both sites can recognize and use to compare entries in this new table where your tracking your users. I'd say keep try by IP, Browser, and maybe a userID all in one cookie with a unique hash of some kind as well thats specific to the user based on something only the servers could recreate on the info they have for the user.
Of course I dumb it down in conceptual speak, its a little more elaborate than I make it out to be, but this would be your general stepping stones.
Also if the sites are independent of one another you could always create an API between them to pass info back and forth JSONP style so one can act as the hub for the login while the other just validates
But in all its all dependent of what your wanting to do overall how, when where, etc..
You can have one application handle logins for both sites using php sessions.
example1.com
user logs in and php session cookie is stored.
ex.example2.net
check example1.com and validate session cookie. if it does not exist redirect to example1.com login page or a custom login page on example1.com. If it does exist, then log the user into ex.example2.net.
If you only want a link then you generate a hash and pass that to the second app once they have logged onto the first. If the hash validates, then log them in.
If it works for you, my suggestion would be to go the openID route. It's the easier way and it's secure enough. Besides, the registration process is easier and quicker to users too.
You can actually only allow IDs from your sign-in domains, if you prefer, making it pretty much a "private" login system.
There are downsides too... You don't have fine control over the registration process, you are dependent of openID authorization process... There are some problems that might happen if your host is not well configured (timezone differences, for instance).
But overall, it's a relatively secure system, easy to implement.
Kerberus is extremely secure but it's a nightmare to work with. Unless you're dealing with highly sensitive user information, like credit card numbers, or think your websites make apetizing targets for hacking I don't think it's worth your time.
I would use a database table that is shared between the two sites. If you go down the PHP session route don't try and just pass the session data from one site to the next on separate domains, it won't work. I found this post helpful many moons ago: Single Sign On across multiple domains
I have a server say 'XYZ' and many clients of different domain, say A, B and C. authentication is done at server.
- when user comes first time to any of the site, we will ask him to create the account for the site. he will enter email and password. we will sent the data to server and stores thr. now he has account in 'XYZ' so that he can login to any of the site A, B and c.
Next:for example say, He come to site B, to login, he enters email and password. we will take this data to server to verify, if password matches with email, we send status 'Yes' back to client so the he login successfully and go to inner pages.
Because sending email and status 'yes' back to clink is not safe. we are using socket programming. so that outside people will not know what data we are sending and getting back.
because we are using socket, we are not able to create any session or cookies, because we are not opening server site in browser.
I want,like: when user successfully logs into site B. if simultaneously in next tab he goes for site C. he should not asked for to login(should not show login page). he automatically gets logged in(goes to inner pages).
The thing you're looking for is called single sign-on (abbreviated SSO) and it is a hard problem to solve correctly. There are lots and lots of SSO schemes, all of which suck horribly in their own special way.
A major obstacle in the way of your goal is how we normally keep track of logins on the web: cookies. In particular, one domain can only set cookies that belong to it. This means that if your three web sites are on three different domains, you can not have one site set a cookie for the others.
A common way around this is to actually place the authentication service on yet another domain name. Whenever you need to check that a user is logged in, you direct them to that authentication service. A popular unified sign-on mechanism, OpenID, uses this technique. OpenID is what StackOverflow uses.
(If you use the various StackExchange sites, you may have noticed that you can sometimes be automatically logged in to the others after loading a page. I'm still not sure how this works, and haven't investigated yet.)
From what you've described, you'd be well-served by central authentication. You may even find that implementing a system based on OpenID could even work well for your sites... though if you do that, I encourage you to hide the complexity of the whole URIs-as-identities thing, normal end-users are unlikely to understand the concept.
Can you set a cookie in your browser after the user logins in the XYZ site?
So now when the user visits the site A, B or C, you can check whether cookie is set against XYZ domain, and if yes, you can login the user. But note that you can only share cookies across sub domains (of XYZ), not different domains.