i'm trying to create a web app with back and front end separated, so there is two project here. The reason is there is a plan in the future to create mobile version as well, so i made it decoupled.
Just FYI the back are created with PHP using laravel4 and barryvdh CORS
and the front end are created purely with angularjs and bootstrap.
The current situation is that i create a rest API in my back end app to do login, auth, and logout.and in the front end i have 2 pages, which is login and index page.
Login page are composed of username, password input field and submit button,
when user click submit button, it will call the login rest API from the back end and i expect it would persist cookie to the front end page if login success, but it doesn't (because of cross origin policy, i've research as much).
The question is, is there any way to set sessions across domains now it is 2014, where any article i found are from 2012 older. If it's not possible, what's the easiest way to persist session across domain besides OAUTH2 and openID (because their learning curve are just too steep, the application i'm creating are just small app)
Thanks for your assistance.
what I have done so far to work with cross-domain sessions is to create a "passport" service on a another domain and validate & handle the session from the there.
For example...
domain1.com has webserver1
domain2.com has webserver2
passport.com has webserver3
Whenever I connect either to domain1.com or domain2.com I'm including a line at the very top of the script index checking on passport.com/check.php whether there's a browser session already initialized under the name of "PASSPORT", if so, I finish the checking on passport.com and let the script on domain1.com or domain2.com to do their stuff.
In case the browser session wasn't initialized, the check.php will redirect the index via header() to the login.php page. This will validate against LDAP and if binding the user is OK then the browser session is initialized with the name of "PASSPORT" and including all the fields I need furthermore to validate the user and its accesses. Ref back to the index once is done.
When the user goes from domain1.com to domain2.com (or the other way around) the script included at the top of each index will check the session again all the time, taking the user to the login script or letting him access the required site.
As additional checking you can create the session and add variables such as "valid until", "access level", etc.
Hope this helps and if you need further clarification let me know.
Best,
Emiliano.
Related
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
In implementation of Login, I want to make sure if a user is already logged in one tab of the browser and opens the same web site in another tab, he gets redirected to homepage rather than the log in page. It's an ideal scenario as it happens in all the web site. I am achieving the same by storing logged in unique user token in local storage. Is it the best way to achieve it? Kindly guide! is it safe? If not how to go about it?
Just consider everything on the client as tainted or possibly manipulated.
So basically you should always check on the server side if the client has a valid session and only then deliver the homepage to it.
I would use a cookie set by the server side - just a random id bound to the actual client session on the server.
So the client could mess with that, but would have a hard time to guess another (also random) session id.
The cookie should be cleared by the server if the user logs out.
Then I would check on every call if he has a valid session id and if not directly send him to the login page by a redirect. Additionally you could then send him from the login page to the homepage whenever he is already logged in.
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.
I've trying to add a messageboard to my Codeigniter web site. Everything has gone well except for one little part: I'd like my log in from the main site to carry over to the messageboard. Since the messageboard is not able to run in Codeigniter, I made a subdomain to run the messageboard in. This means that the main site and the messageboard do not share cookies. The messageboard is Phorum-powered, so there's a hook that I can use to sign in if I have the user_id of my user. In other words my problem basically boils down to being able to run a function on one domain that can get the user_id variable stored in the session of another domain.
Here are things the I've tried:
Setting up a controller in codeigniter that uses ci->session to echo the user_id. Then in the messageboard, I used CURL to fetch me the output of the codeigniter controller. This doesn't seem to work because CURL doesn't carry cookies or sessions or something, so codeigniter can't access it's session when called through CURL.
Same thing but with file_get_contents. File_get_contents is disabled on my server.
I'm pretty much out of ideas. Does anyone know a function I could write that would get me a CI session stored user_id from a different domain?
Here are two things you can try:
1) host the forum in a subdirectory of your code igniter project. So your two websites will have the url http://mysite.com/ and http://mysite.com/forum. Now that they share the same domain, you can access the session.
2) In your forum login page, display the message "auto-signing in". On that same page add an iframe in the html with the src="http://mysite.com/autologin/tokenid", but hide it with css. The autologin page will have CI session information, which you can temporarily make available to the world via a hard to guess tokenid and by echoing $_SESSION['user_id']. Remember to expire this page when you are done with it. Then refresh the forum's login page and use CURL to grab the publicized session information at http://mysite.com/autologin/tokenid. This is full of security flaws, so do it only as a last resort.
Updated with clarifications
Hello,
When our users go to http://mysubdomain.server.com/login they get redirected to https://secure.server.com/login?subdomain=mysubdomain. So the actual login page is located on the secure.server.com subdomain.
The problem is that if the user logs in with the credentials meant for subdomainA and tells Firefox to remember the password, the browser will autocomplete the login form even if the user visits the login page meaning to log into subdomainB.
Firefox assumes that the login form on secure.server.com/login?subdomain=subdomainA is the same with the one on secure.server.com/login?subdomain=subdomainB.
At first, I thought Firefox remembers passwords based on a combination of the URL and the name attribute of the form, but I've tried changing the name based on the subdomain (name="login-<subdomain_name>"), and it still doesn't work.
How can I make Firefox remember passwords for subdomainA and for subdomainB separately, and not together?
I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.
I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.
[edit]
source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.
If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.
I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?
AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.