I just simply configured the express-session middleware and express subdomains, but when I login on accounts.example.com I am not being logged in in example.com or any other *.example.com
I tried to use cookieParser with cookieSession but it didn't worked
Related
I am developing a website using Vue.js, and I have implemented HTTPS in my webpage.
Right now the website is basically static, no communications between itself and the backend server.
If I wanted to add features for instance, login, via a backend server which is on the same machine as the frontend server.
Do I need to get another SSL certificate to make to communication between frontend and backend through HTTPS?
Is there any way to make the SSL certificate work on the whole domain?
You have a few options here
Proxy API requests to your backend service
This means that your HTTP server (eg NGINX) uses your built Vue app (eg the dist folder contents) as its document root and creates a reverse proxy for requests to your API service. For example, say you have a backend service running on port 3000
location /api {
proxy_pass http://localhost:3000/
}
Then your Vue app can make requests to /api/whatever.
During development, you can mirror this using the devServer.proxy setting in vue.config.js
module.exports = {
devServer: {
proxy: {
"^/api": "http://localhost:3000/"
}
}
}
Use a wildcard certificate and run your backend service at a sub-domain, eg
Frontend - https://example.com
Backend - https://api.example.com
Just get two SSL certificates for your two domains. They're free after all
Keep in mind, options #2 and #3 will need you to enable CORS support whereas that is not required for option #1.
I have webpack-dev-server serving static files. (localhost:4000)
I have backend server serving api request. (localhost)
Before that, there is a authentication with idp provider.
when I visit localhost:4000, it gets proxied into localhost for authentication.
localhost server redirects to idp for authentication, once authenticated idP redirects back to 'localhost'. Now this is the problem. I want it to be redirected to localhost:4000 not localhost.
Is there anyway to achieve this?
The above configuration has an asp.net core app using google authentication. But for some reason the authentication redirect to Google was sending a redirect URI using http instead of https. No matter where I look, there doesn't seem to have a way to change this in the middleware.
On the apache side, I followed a tutorial that supposedly forwards the protcol using
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
However it does not work correctly. More information below and interesting security ramifications.
Now, since kestrel is running http it defaults to setting the "redirect URI" for google authentication to use the http protocol.
I have the above scenario working with http redirect URIs. I've wiresharked this and it works with the HTTP redirect URI! Hmm, I'm only allowing https in though. So I tcpdump the interaction on my server and I find that because apache requires https, it throws an HTTP 301 moved permanently to https. Great that's what I would expect. What I didn't expect was Google to redirect to the https protocol. OK, not ideal, but it works so why am I asking? It sends the data over http first to get the 301 so I've lost encryption at that point. If someone is snooping, they can read Google's entire response. I.e. I can see google post back on http with tcpdump.
Below is the only code relating to Authentication:
services.AddAuthentication(options =>
{
options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddGoogle(options =>
{
options.ClientId = Configuration["Authentication:Google:ClientId"];
options.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
})
.AddCookie(options =>
{
options.LoginPath = "/auth/signin";
});
Note, that in my code I am NOT using app.UseHttpsRedirection();
Although, I'm still interested in finding a way to change the value of the Redirect URI sent to google from asp.net core using the ".AddGoogle" authentication, I was able to solve the problem by changing the apache configuration to:
RequestHeader set "X-Forwarded-For"
RequestHeader set "X-Forwarded-Proto" "https"
Essentially hardcoding the protocol forced it to pass "https" to the asp.net core middleware and it now works correctly.
I want to have my main app accessable at mydomain.com
From here I also want api.mydomain.com and staging.mydomain.com
I use DigitalOcean and Dokku, along with letsencrypt SSL
I have now sat up my main app at production.mydomain.com, can i redirect visitors to mydomain.com, from here?
How is this achievable?
Make sure you add your domain (e.g. example.com) to your app:
dokku domains:add yourappname example.com
Then in your app you can issue a redirect when people access it via production.example.com:
// ExpressJS
res.redirect(302, 'https://example.com');
I am building a chrome extension. In it, I use this code:
new WebSocket("wss://api.example.com/");
The problem is that the website with the cookie in my browser is WWW.example.com so WebSockets wont pass the session cookie.
What I need is this:
new WebSocket("wss://api.example.com/", { "cookies": [ { "session": sessionKey } ] });
How can I achieve this?
The domain that created the cookie gets to decide whether subdomains are allowed to see the cookie or not. Only the creator of the cookie can do anything about that. If www.example.com sets the cookie on example.com and allows subdomains to see it, then api.example.com will be able to see it. Otherwise, api.example.com will not be allowed to see that cookie. That's just how browser security works.
If you know the sessionKey in your Javascript, you yourself can set that into an example.com cookie that allows subdomains and then it will be automatically sent with the webSocket request to www.example.com. You don't send cookies explicitly. You set cookies on your domain and allow access to subdomains. Then, the cookies will get sent automatically on both Ajax calls and webSocket connect requests.
In your specific case, you can do this:
document.cookie = "session=" + sessionKey + ";path=/;domain=example.com;"