I've recently tried moving an ASP.NET core 3.0 application from a windows server to a Linux server.
The application shares cookie authentication with another website so the cookie domain needs to be a wildcard to share across the sub-domains i.e. .example.com
This works fine on the Windows server the cookie domain for https://sub.example.com gets set as .example.com
However, when I login on the Linux server the cookie domain for some reason gets set with the sub-domain. For example for https://sub-test.example.com the cookie domain is .sub-test.example.com, which then won't be shared with https://sub.example.com, hence the problem.
I've checked the network tab in the browser and the set-cookie header has "domain=.sub-test.example.com", so I'm convinced it's a server side problem.
In Startup.cs, I have hard coded the domain wildcard I want, it just doesn't get honoured on Linux.
services.ConfigureApplicationCookie(opt =>
{
opt.Cookie.Domain = ".example.com";
}
Not sure what else I can try.
Sounds like an issue with a Reverse Proxy, which is probably overriding the settings you set there. Take a look at the this post: URL Rewrite keeps original host Location when reverse proxy 301 redirects
Related
I recently bought a domain name at OVH for an app I hosted on Heroku. I then paid for the dynos in order to set an automatic SSL certificate.
Everything seems to me working fine:
Domain Status Last Updated
─────────── ─────────── ────────────
mpjrigot.eu Cert issued 2 minutes
mpjrigot.fr Cert issued 2 minutes
But my URL is still in HTTP. What am I missing?
EDIT
I'm using React.js for this app
I also have a Ruby on Rails back but for nom i'm keeping that on the heroku.app, works fine
2nd EDIT
Using react-https-redirect, force-https or react-ssl-redirect...
Basically, chrome tells me that "this is not a safe space", and that this is a fake https that might want to steal the user's passwords and stuff
So I got an SSL that is set on my HerokuApp,
I got a domain on OVH that points to the IP of the app
But the http isn't secure somehow
I really think I missed something obvious as I'm new to this...
You can add HTTPS to your app with the following methods.
Method1 (Recommended)
Since, you're using rails for the backend, you can configure your rails app to always use HTTPS.
in your production.rb add
config.force_ssl = true
More Info: https://help.heroku.com/J2R1S4T8/can-heroku-force-an-application-to-use-ssl-tls
ActionDispatch SSL: https://api.rubyonrails.org/v6.1.4/classes/ActionDispatch/SSL.html
Method2 (Easy Setup)
You can also signup for cloudflare's free plan and easily setup https redirects with cloudflare's 'Always Use HTTPS' or 'Automatic HTTPS Rewrites' feature.
The 'Always Use HTTPS' feature will redirect all http requests on your site to https address.
The 'Automatic HTTP Rewrites' feature will change the HTTP links on your site to HTTPS links.
More Info here:
Always use HTTPS: https://blog.cloudflare.com/how-to-make-your-site-https-only
Automatic HTTPS: https://www.cloudflare.com/website-optimization/automatic-https-rewrite/
Cloudflare's SSL: https://www.cloudflare.com/ssl/
cloudflare dashboard
What am I missing?
Heroku provides a certificate, so you should be able to access your application using https://. However it does not redirect HTTP requests to HTTPS for you:
Redirects need to be performed at the application level as the Heroku router does not provide this functionality. You should code the redirect logic into your application.
Exactly how you do that depends on the language and libraries or framework that you are using. Several common examples are listed in the link I provided above.
If you edit your question to tell us what technology you have used to build your application I'll be happy to add those details to this answer. In case you are using Scala, please see How to disable HTTP requests on Heroku and/or auto-redirect to HTTPS?
solution
I eventually read about Heroku needing a specific host that takes in the address they tell you to point to when setting a domain name...
So I switched to Gandi for my domain name and set the ALIAS to point to said adress
Works like a charm
I'm integrating Azure AD into a server side blazor application. It works locally (using https), however when I deploy it to production, the redirect URI in the URL is HTTP, not HTTPS, which then once I log in, Microsoft say the redirect URI isn't valid.
I'm running a VM using Ubuntu and Apache, which is forwarding anything from port 80 to port 443 using a Lets Encrypt certificate, however when it sends the user to Microsoft to login, the redirect URI is http://mydomain.tld, rather than https://mydomain.tld. I think it's because the URL it's running on locally is http://localhost:9000 - But when I put it to https://localhost:9000, it throws an exception on start up as it doesn't have a certificate and as I'm not running on a development machine, I don't really want to install the net core SDK and create dev certificate.
I've seen a few people put this in their code to solve it, however my requests are still going through to Azure AD with a HTTP redirect URI:
var fordwardedHeaderOptions = new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
};
fordwardedHeaderOptions.KnownNetworks.Clear();
fordwardedHeaderOptions.KnownProxies.Clear();
app.UseForwardedHeaders(fordwardedHeaderOptions);
Any ideas on how to fix it? I can't imagine I'm the first to be using Blazor behind Apache and connecting via openid.
Two options:
1.Set up Redirect URIs: http://localhost/****
2.Edit the Manifest like below:
I have purchased a domain name successfully on google domains. I have the website and server deployed on Heroku, which has provided us with a DNS target and a positive ACM status. When navigating to the site by clicking the link provided by the google search, SSL is not active. However, typing into the address bar "https" will cause it to use SSL as will just typing [domain-name].ca, BUT typing "http", it will not use SSL. Why is google defaulting to the non-SSL version?
I have set up the synthetic record:
#.[domain-name] -> https://www.[domain-name].ca
on google domains
Shouldn't this forward every request to https?
I do not have any http calls in my code.
Depending on what enviornment you are using, you need to enable force ssl config.
Rails
Use config.force_ssl = true in your config/environments/production.rb or similar.
Node (Express.js)
Use a package to set this up for your app. Some options can be found here: https://www.npmjs.com/search?q=express+ssl
PHP
You can add directives to the .htaccess file at the root of your project to do this. See this SO post for an example https://stackoverflow.com/a/34065445
Django
Set SECURE_SSL_REDIRECT to True.
Flask
You can use https://github.com/kennethreitz/flask-sslify to handle this for you.
We have an application runing on Weblogic 10.3, with authentication provided on the application itself. We want to put the Weblogic behind an Apache server. The idea is that we will have some public content on the Apache server, and the application will be accessed through the reverse proxy. That's pretty much very standard. The issue comes with the fact that there are some contents on the Apache server that can only be accesssed if the user has logged in the application. So basically the Apache server will server three type of contents, on diferent URIs:
/ -> Will contain the public information, and will be server by the Apache
/myApp - > Will be redirected by the Apache to the weblogic behind
/private - > Will contain the private static information. This should only be accessed if the user has previously logged successfully in myApp.
My question (I'm a total newbie with Apache) is if this possible. My idea is that the application can put a cookie on the responses indicating if the user has logged on the application, and that the Apache will check for that cookie when the user tries to access /private.
Any thoughts?
The / public information is no problem, it's straightforward. Using ProxyPass or ProxyPassMatch to reverse proxy "/myApp" to your internal Weblogic server is also straightforward. You may need to use a couple of other options to make sure proxy hostname and cookie domains are setup correctly. But setting up static protected infrormation in "/private" is going to be a little more tricky.
1) You can check the existence of the cookie set by myApp using mod_rewrite, something like this:
RewriteCond %{HTTP_COOKIE} !the_name_of_the_auth_cookie
RewriteRule ^private - [F,L]
The problem with checking a cookie through something like this is that there's no way to verify that the cookie is actually a valid session. People can arbitrarily create a cookie with that name and be able to access the data in /private.
2) You could set it up so that anything something in "/private" is accessed, the request is rewritten to a php script or something that can check the cookie to ensure that it's a valid session cookie, then serve the requested page. Something like:
RewriteRule ^private/(.*)$ /cookie_check.php?file=$1 [L]
So when someone accesses, for example, "/private/reports.pdf", it gets internally redirected to "/cookie_check.php?file=reports.pdf" and it's up to this php script to access whatever it needs to in order to validate the cookie that /myApp has setup. If the cookie is a valid session, then read the "reports.pdf" file and send it to the browser, otherwise return FORBIDDEN.
I think this is the preferable way of handling this.
3) If you can't run php or any other scripts, or the cookie cannot be verifed (like with a database lookup of session_id or something similar), then you'll have to proxy from within WebLogic. This would be more of less the same basic idea as having access to "/private" through "cookie_check.php" except it's an app on the WebLogic server. Just like /myApp, you'll need to setup a reverse proxy to access it, then this app will get the request (which has been internally rewritten from "/private/some_file") check the cookie's validity, read the "some_file" file ON THE APACHE SERVER, then send it to the browser, or send FORBIDDEN. This is the general idea:
ProxyPass /CheckCookie http://internal_server/check_cookie_app
RewriteCond %{REMOTE_HOST} !internal_server
RewriteRule ^private/(.*)$ /CheckCookie?file=$1 [L]
This condition reroutes all requests for "/private" that didn't originate from "internal_server" through the /CheckCookie app, and since the app is running on "internal_server" it can access the files in "/private" just fine. This is kind of a round-about way of doing this, but if the validity of session cookies issued by /myApp can only be checked on the WebLogic server, you'll have to reroute requests back and forth or something similar.
We recently installed a web application under Tomcat 6 which is connected over the isapi redirector interface (see http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html) to an IIS 7 server. The connector works properly in every case, except for some pages in the web application that return a status 302, with a new location to redirect for.
The browser gets the 302 back and requests the new location, but the IIS web server does not forward the request to the Tomcat server and returns a 404 error instead, even though the uri worker map looks correct for me.
The corresponding uri worker rule is:
/WebClientServlet/*=worker1
and the location url of the new location looks like the following:
http://localhost/WebClientServlet/SBS/cmd:editContent2/workflow:false/articleSearch:false/confirmed:false/objectID:131294/---/fpse/db:test/objectID:131294/Copy+of+0001-Intranet+Home-main-ip+%28DE%29
I could solve the problem. The HTTP status code was actually a 404.11, which means (under IIS 7) that double escaped sequences are not allowed. There is a new feature introduced in IIS 7 called double escaped URL filtering. It is a default security filter, which denies to load any URL that contain double escaped sequences. In order to solve the problem, switch the feature off for the web site which is used to access the tomcat application over isapi-redirector. See more under http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering.
Ditch the ISAPI redirector. Up until today it is what I have been using. Check out the Application Request Routing for IIS7. Here is a walk through on how to set it up. If you want to use host headers look here.