I have 2 Asp.Net Core 2.2 applications and I want to share session between them. I've set up session in a SQL database and both connect ok. They are on different sub domains. I understand that I can set the Cookie.Domain the startup file, which would solve the problem at a basic level, so each application would create the cookie such that it can be accessed. e.g.
Domain 1. "www.website.com"
Domain 2. "dashboard.website.com"
At present these sites can't access each others session cookie.
If I set the domain cookie to ".website.com", both should be able to access this.
The problem is that we have multiple domains that use this website, so it could be:
www.domain1.com
dashboard.domain1.com
www.domain2.com
dashboard.domain2.com
www.domain3.com
dashboard.domain3.com
I need to be able to inject the current host name into the startup cookie domain, in order to have it dynamically set, depending on the domain of the active website.
Is this at all possible?
Just to clarify, www.domain1.com does not need to be able to access www.domain2.com.
Only the www. and dashboard. variations of each domain need to be able to connect to each other.
Thanks in advance,
David
To share sessions across applications, you need only follow the directions in the docs. It basically boils down to two things:
You need to persist the data protection keys to a common store that all the apps can access. A UNC path will do, or you can even use something like Azure Key Vault.
You need to set a common application name. Data protection values are segregated by application by default. Setting a custom name, which is then used across all the apps allows them to all access the same set of data.
As far as setting the cookie domain goes. There's no good way to do this by convention. The actual domain name is only available in the context of the request pipeline, which is not available to you in something like Startup (there's no request). Even if you could, it's not reliable anyways. In situations where you have a reverse proxy or, importantly , when hosting in containers, the domain will be localhost, since the actual domain isn't applied directly to the app.
Long and short, your best bet is to use configuration. You can, for example, have environment-specific JSON files like appsettings.Domain1.json, appsettings.Domain2.json, etc. Inside each, you can add a something like:
{
"CookieDomain": ".domain1.com"
}
Then, when you deploy, you set the environment to the appropriate domain, and that config file will be used. In Startup, you'd just do:
services.ConfigureApplicationCookie(o => {
o.Cookie.Domain = Configuration["CookieDomain"];
});
Related
I'm building an application that has a core hub, say it's called musictickets.com
We'll provide a subdomain (bandname1.musictickets.com) to bands on which only their content will display, which they can mask using a CNAME record to be part of their domain - so tickets.bandname1.com
There would be multiple bands using the platform so you'll end up with pages at
tickets.bandname1.com
tickets.bandname2.com
etc.
I'd like a user who registers at tickets.bandname1.com to be automatically logged in on every site that uses the service, including the parent, musictickets.com . They should be able to register/login using OAuth or directly via form based authentication.
I'm looking at SAML (specifically https://github.com/aacotroneo/laravel-saml2) as one option, but want to throw this out to the wider community for comment.
I've also looked at using token based SSO as described here (single sign on (sso) laravel) and running an auth server (which I may do in any case). Alternatively, I've looked at using iframes to provide the functionality which feels quick but dirty.
As I understand it, I wouldn't be able to use cookies (for an API key for instance) because whilst all of the content will be displayed via a subdomain, the CNAME would make it a different domain.
Does anyone have any thoughts on the best strategy?
Can I use Let's Encrypt to generate SSL Certificate even if I don't own the domain name? The scenario is I have a site that lets user create their own sort of page inside my site which would be a subdomain under my main domain. Now, there's a feature that they can use their own domain name (using a different provider) that will point to the created page on my site so they can use any domain name that they want.
Will I still be able to provide SSL using Let's Encrypt to my user? Note: I'm new at this thing so I am not sure if I am asking the correct question, but I am asking as how I understand it right now.
Yes.
The validation occurs based on HTTP file retrieval or via DNS through TXT records.
I built Greenlock to be able to handle exactly that kind of use case. It will currently work for the scenario that you suggest and I plan to implement more DynDNS support in the future.
I’m using Spring and Spring Security 3.1.4.RELEASE. I am logged in, with session established on one subdomain — https://main.mydomain.com/myapp but I would like to redirect the user to a different subdomain, e.g. https://second.mydomain.com/myapp but keep the user logged in. How do I do that? I don’t want the user to have to login a second time but I would like something secure .
I can upgrade Spring if it solves my problem.
In order to share application sessions, you'd need two things (not really Spring related actually):
the session cookie should be set on the shared domain mydomain.com and not on a subdomain main.mydomain.com
sessions should be stored in a shared repository (such as redis)
This can be tricky, because those two applications now need to be in sync regarding what's stored in session. Serialization, change of implementation, etc can render this strategy useless.
If you're looking for Single Sign On, then you should take a look at the various SSO implementations out there.
I have two applications running on Tomcat, JSF 2 Mojarra 2. Both applications are mapped to the same domain but each to a different pattern within this domain. One application is used as a front page while the other is used to access protected resources (don't ask why not all in one app, it's been design deliberately to separate the apps as two different entities, each responsible for it's own thing). Now the question is: is it possible, and if it is, how to pass the session state between those two separate apps. To illustrate here are some common situations:
A user does something on the main application running the website and then logs in and whatever he/she was up to doing is being taken to the new session after login to the new app.
(This one is slightly more complex I think) The user registers in the first app and is automatically logged in upon successful registration into the other app. The app where yo have to log in is using j_security_check form login (this would be the hard part)
Several ways:
Store the data in DB which and identify it by a long, unique, hard-to-guess autogenerated key which you in turn also store in a domain-wide cookie. This way the both applications can get the data from the DB based on the key found in the cookie.
Expose the ServletContext of the both applications to each other. In Tomcat, it's a matter of adding crossContext="true" to the <Context> element of the webapplication's context.xml. This way you can get the each other's ServletContext by ServletContext#getContext(). Finally put some Map<String, SomeData> in there which is keyed by some ID which is shared between the both applications, for example the logged-in user ID (you should only ensure that the same user can't have more than one session).
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.