We've decided not to use SSL anymore and unfortunately our server guy has quit and now I need to fix this. I've revoked the certs from Comodo, removed the SSL app from Heroku but that was apparently not enough and now we have serious problems with our site.
When visiting inteokej.nu one gets redirected to the app, but automatically http turns to https and instead of showing the domain (inteokej.nu) the app link is shown https://inteokej.herokuapp.com (I want inteokej.nu to be shown, not the actual app link).
That is a problem but not the biggest problem, which is that it's not possible to use the site anymore (e.g login, the static pages works though). When I try to login I first get a https security error and when I proceed I get to the following page: https://www.inteokej.nu/cgi-sys/defaultwebpage.cgi ("Sorry! If you are the owner of this website, please contact your hosting provider: webmaster#inteokej.nu").
I've now learned the hard way that SSL is a complex thing but I really need to get this site up again as soon as possible. So, where should I start and how could I proceed from this point? I guess there's some back end coding that should be done in the django code as well?
Thanks a lot in advance!
Your issue doesn't seem to be with SSL but DNS or at least however your server guy set things up.
The error page you're seeing isn't a Heroku error, inteokej.nu isn't being hosted on Heroku but on a server run by your DNS provider svenskadomaner.se .
If you use the Firefox Live HTTP Headers plugin you can follow the request/response cycle and you'll see that there is a 301 redirect from www.inteokej.nu to inteokej.herokuapp.com (probably an .htaccess redirect).
Check the DNS records for your domain (like here http://viewdns.info/dnsrecord/?domain=inteokej.nu ) you'll see that there is no CNAME record to Heroku, only an A Record to 46.22.116.5 which is an IP Address owned by svenskadomaner.se.
So the thing to do is to set up the custom domain as recommended on Heroku's site:
https://devcenter.heroku.com/articles/custom-domains
and set the CNAME to Heroku's recommendation.
One reason your server guy might have set things up like they did is that Heroku doesn't easily allow "naked domains", so people often do .htaccess redirects from example.com to www.example (which does work easily with CNAMEs).
Good luck!
Related
My Flask web application requires a Microsoft login feature.
The Microsoft login requires a redirect url that redirects the user back to Flask after successfully login in Microsoft.
My HTTPS structure is: Nginx listening at 443, and proxy all request to http://127.0.0.1:5000, where my Flask app is running.
(The most popular method I found for running Flask as production mode using HTTPS )
Now comes the problem: The redirect url sent to Microsoft login, is http://127.0.0.1:5000
But all other redirects, e.g.: (ignore my function names, you know what I mean)
resp = resp.set(url_for('index'),200)
return resp
or
return redirect('/whatever_page')
are all redirected as https://example.com/{whatever_page}, which is completely fine.
But when it comes to the redirect url used in Microsoft login, it failed.
The Microsoft login code I am using is basically the flask demo I downloaded from Microsoft, all I did is simply changed the entire thing into another function of my Flask app, and call it when I need it. I did went through the codes step by step and did everything I could to make things right, yet nothing worked.
I have tried changing the IP in proxy_pass to the public IP and some other IPs, they didn't work but I can see the IP used in redirect url changes with the proxy_pass IP.
I have tried many configurations that might make things right, for examples:
proxy_redirect: http://127.0.0.1:5000/getAToken http://example.com/getAToken
or
proxy_redirect: http://127.0.0.1:5000/ https://example.com/
or
proxy_redirect: http://127.0.0.1:5000/ http://example.com/
or
proxy_redirect: http://127.0.0.1:5000/getAToken https://example.com/getAToken
Exedra
None of the proxy_redirect configurations can affect the redirect url used in Microsoft login, but all other redirects work.
I even tried to change the redirect url manually by modifying the login url Microsoft generated, it didn't work since the redirect_url is used to encrypt the token or whatever it is.
My current hacky options are:
Running back to developmental using HTTPS, but I need to restart the service every 1h or so to avoid the "not responding" problem in developmental server. Costs are: Lost of cache and potential crash when more users come. (which is what I am currently using to keep the website up)
Use a window server. Developmental mode on window server doesn't stop responding, it may at some point but I honestly don't know, I do have one running for months and never stop responding. The problem here is I don't know when it will stop responding.
Buy another server and use it as a login server, it can be restarted every hour since
cache or whatever is doesn't matter there.
But I really want to solve this problem without using any options above, and modify the redirect URL before the Microsoft login url is generated is the best option I can think of, I just don't know how to.
If there are other options other than these, please let me know, I will really appreciate it.
So, I have two Flask apps running on localhost, one on the port 5001, and the other one on the port 5003, and apparently both are using the same session. If I log in on one app, it logs out on the other. And for example, recently, if I logged in using my email on one app, it would also log in my account on the other app, since I have users using that email on both apps, and I was using the email as an user identifier, but that stop happening when I used another id for the users.
I'm using Flask-Login, and Google Chrome (the same thing happens in Edge).
I'm not really sure if this could also happen in production, we'll probably use the same host for both apps, so that would be a problem. If this is something related only to localhost, then it's ok, but I don't think that's the case.
Any idea of what could be happening here?
Thanks in advance.
I had a similar problem, and I think the cause is that both instances would use the same "session cookie" in the browser.
The solution that fixed it for me was renaming the SESSION_COOKIE_NAME which is session by default.
app.config.update(SESSION_COOKIE_NAME=<new_session_name>)
I found the solution via: https://stackoverflow.com/a/45497948/380038
I'm running Python3.4 with flask 0.10.1 and I'm trying to implement HTTPS so that my login pages etc are encrypted.
My book on Flask Web Development suggests that SSLify will do what I want but all that happens is that I get BAD requests with a load of encrypted data in the header and there is no way to specify the SSL encryption keys it seems other than to use heroku which I don't think is an option if I have understood what it is correctly because my server will run on a network with no internet access and heroku is an internet cloud service. Looking at the SSLify documentation it does not mention anything about needing a cloud service for it to work only that 4 lines of code and you have a working HTTPS server. So I'm clearly not understanding something there or the documentation assumes the reader is a web GURU which obviously I'm not. :-)
So I then took a look at pyOpenSSL to load the keys and create a context but it hangs forever on the line:
context.use_privatekey_file(os.path.join(basedir, 'certs\\server.key'))
Now my key file is encrypted with a password so I have no idea how everyone else is doing this when I see other posts on the internet as I cannot find out how to tell OpenSSL what the password is when specifying the key file?????
I think I'm completely barking up the wrong tree here so can anyone out there point me in the right direction please?
I'm sure this question is easily googleable, but I can't seem to find the right query to find the answer I want.
I'm running several apps on my home server that all serve their own website for admin and info purposes. Currently I access them all from the internet using http://MyHouseServerAddress.com:8080 etc. Where 8080 is replaced with 8081, 8082 etc. for each app. They all have their own usernames and passwords and some of them use SSL
What I want is to have a single access point, e.g. http://MyHouseServerAddress.com which gives me access to each app. Each app will have a link on that page which will take you to that app's website as if it were just a page on the main site. However... I want the single access point to be password protected and SSL'd, BUT I want to remove the passwords from all the apps as they would be accessed through the single "portal" of the initial page which is password protected and SSL'd. I.e. each app would still serve on it's original port, but that port would no longer be accessible via the internet, instead any traffic from that port would be routed through the single access point.
What I'm trying to do it get a single password login, preferably via SSL to my home server which gives me access to all my other serving apps but also secures them all behind the single login.
Can this be done with a python script or a C# app for instance running some sort of proxy or port forward script? Or would running an Appache server that can redirect traffic through itself work? I'm happy to write code to solve the problem if needed.
I hope this makes sense!
I'm running W7 on my home server.
Thanks,
Max
This sounds very much like a portal with single sign-on. I haven't tried, but you might get away with implementing oauth on your sites and have the main site be the provider.
Other way would be to use soemthing like CAS.
Look at this question for options.
You can install Apache+PHP on port 80, install PHP Web Proxy on it, allow local access to your apps (so they allow access without password from localhost) and secure this gateway with .htaccess and .htpasswd, or another way.
This is most simple solution for home using. Good enterprise solution would be SSO, bad it is not simple.
I am using google app engine's urlfetch feature to remotely log into another web service. Everything works fine on development, but when I move to production the login procedure fails. Do you have any suggestions on how to debug production URL fetch?
I am using cookies and other headers in my URL fetch (I manually set up the cookies within the header). One of the cookies is a session cookie.
There is no error or exception. On production, posting a login to the URL command returns the session cookies but when you request a page using the session cookies, they are ignored and you are prompted for login information again. On development once you get the session cookies you can access the internal pages just fine. I thought the problem was related to saving the cookies, but they look correct as the requests are nearly identical.
This is how I call it:
fetchresp = urlfetch.fetch(url=req.get_full_url(),
payload=req.get_data(),
method=method,
headers=all_headers,
allow_truncated=False,
follow_redirects=False,
deadline=10
)
Here are some guesses as to the problem:
The distributed nature of google's url fetch implementation is messing things up.
On production, headers are sent in a different order than in development, perhaps confusing the server.
Some of google's servers are blacklisted by the target server.
Here are some hypothesis that I've ruled out:
Google caching is too aggressive. But I still get the problem after turning off cache by using the header Cache-Control: no-store.
Google's urlfetch is too fast for the target server. But I still get the problem after inserting delays between calls.
Google appends some data to the User-Agent header. But I have added that header to development and I don't get the problem.
What other differences are there between the production URL fetch and the development URL fetch? Do you have any ideas for debugging this?
UPDATE 2
(First update was incorporated above)
I don't know if it was something I did (maybe adding delays or disabling caches mentioned above) but now the production environment works about 50% of the time. This definitely looks like a race condition. Unfortunately, I have no idea if the problem is in my code, google's code, or the target server's code.
As others have mentioned, the key differences between dev and prod are the originating IP, and how some of the request headers are handled. See here for a list of restricted headers. I don't know if this is documented, but in prod, your app ID is appended to the end of your user agent. I had an issue once where requests in prod only were getting detected as a search engine spider because my app ID contained the string "bot".
You mentioned that you're setting up cookies manually, including the session cookie. Does this mean that you established a session in Dev, and then you're trying to re-use it in prod? Is it possible that the remote server is logging the source IP that establishes a session, and requiring that subsequent requests come from the same IP?
You said that it doesn't work, but you don't get an exception. What exactly does this mean? You get an HTTP 200 and an empty response body? Another HTTP status? Your best bet may be to contact the owners of the remote service and see if they can tell you more specifically what was wrong with your request. Anything else is just speculation.
Check your server's logs to see if GAE is chopping any headers off. I've noticed that GAE (thought I think I've seen it on the dev server) will chop off headers it doesn't like.
Depending on the web service you're calling, it might also be less ok with GAE calling it than your local machine.
I ran across this issue while making a webapp with an analogous issue- when looking at urlfetch's documentation, it turns out that the maximum timeout for a fetch call is 60 seconds, but it defaults to 5 seconds.
5 seconds on my local machine was long enough to request URLs on my local machine, but on GAE it was only consistently completing its task in 5 seconds about 20% of the time.
I included the parameter deadline=60 and it has been working fine since.
Hope this helps others!