I have a web app on domain a.com, that requires authentication via a sso service with a return in the url on domain b.com.
the sso service receives the request from the browser, and returns a cookie to the return url specified in return url.
however, because the app domain and sso service domain are different, im unable to set the cookie in the browser for the app on domain a.com due to cross domain cookie restriction.
i have been trying to use nginx as a reverse proxy, whereby the call to the sso service is made via a a proxy running in the same domain as the app, which then returns as 301 to the sso service on domain b.com.
i'm struggling to work out how I then process the return response from the sso service in order to set the domain on the cookie to a.com domain.
any help appreciated!
my server block in nginx:
server {
listen 3002;
server_name server.a.com;
location / {
return 301 https://sso.b.com/Logon/v1/auto? returnUrl=https://service.a.com/Home;
}
}
Related
Imagine the following scenario:
The user goes to http://example.com
The server redirects to the secure version https://example.com using a temporary redirect (status 302)
https://example.com responds with an HTTP basic auth challenge (status 401)
The user successfully provides username/password and access is granted (the browser stores these credentials in its internal cache)
What happens if the user follows a link to the unsecured version of the website (http://example.com)?
Would the credentials be exposed due to the clear-text HTTP request?
Are HTTP credentials and HTTPS credentials stored in separate "buckets" by the browser?
Technically, the two URLs belong to different origins so the credentials should not be shared. But I could not find any confirmation of this online.
Are HTTP credentials and HTTPS credentials stored in separate "buckets" by the browser?
Yes, and those buckets are officially called 'origins'. Specifications like HTML, Javacript, HTTP and URIs talk about origins, but the bucket is effectively the URI minus the path.
So for https://example.org/foo/bar, the origin is https://example.org
So this includes:
The scheme (http / https).
The domain
The port
So in your example the 2 relevant origins / buckets are http://example.com and https://example.com and they are separate.
I am calling API at https://engine-beta.mydomain.com/list* inside http://localhost.mydomain.com website, API response with set-cookie: with domain landing.vahanacloud.com. The browser is ignoring(not saving) this cookie.
But with the same scenario, in API response with set-cookie: with domain .maydomain.com is working fine.
It is because you host domain and you domain is different.
Host Domain: Where the api is deployed.
App Domain: Where you web app is running.
If you save cookie to parent domain, all the sub domain will have access to cookies but siblings domain will not have access to other sibling cookies.
I am about to move my website/App from https://www.example.xx to https://www.example.com
I am thinking about making a redirection in the .htaccess from the .xx to the .com
The question is shall I renew the https certificate on the .xx bearing in mind that some users might have bookmarks to https://www.example.xx ?
What would happen if a user tries to reach the .xx url on https after the certificate expires and the .htaccess having a redirection to the .com?
If application is hosted on the same server (assuming, you just change DNS address for your app) and you own both domains, you would need to purchase single certificate for both URLs: www.example.tld and www.example.com and bind this certificate to web site.
and you will have to maintain both URLs in the certificate until all users update their bookmarks to point to a new web site.
HTTPS redirection requires valid SSL certificate for all redirection URL.
We are setting up a website with secure and non secure pages. These have been added for mapping in uriworker.properties. The domain name in the urls are different . Example nonsecure url is x-y-z.a.b.org and our secure url is x-y-secure-z.a.b.org.Both of these domains are part of our DNS entry. We do not have any redirect rules configured within the webserver. But when we try to access the secure url https://x-y-secure-z.a.b.org, webserver is sending the request as http://x-y-secure-z.a.b.org:443. Due to the scheme not being https , the application does not identify this as secure request and is returning a 302 to the https url. This redirection happens infinitely and then an error appears which says that page is not redirecting properly.
After a lot of analysis , we figured out that the application had a hardcoded check on the scheme of the domain name to be in a certain format as secure.xyz.
I have two website, Site A and Site B.
Site A is on the DMZ area where allow public/anonymous sending http request (one of the client http request data), and i would like the request to redirect to Site B(internal secure host which only allow internal http request)
My question is, Site B is setup with basic authentication REALM. but public/anonymous http request doesn't support Basic REALM. is there a way in the IIS Site A to redirect the request with authentication so Site B could accept the request with REALM
I have found a way to resolve the above question by using Microsoft ISA Server