4 ms·
I would love to switch the whole site to https, but it's not that easy. The login request is always sent via https, even when you are using the site over plain
by steveridout 11y ago
I would love to switch the whole site to https, but it's not that easy.
The login request is always sent via https, even when you are using the site over plain http. So your password should always be encrypted.
The site does work over https (try it - https://readlang.com https://readlang.com), and at one point I redirected all http traffic to https, but there was a big problem. I use external dictionaries in an iframe to provide additional definitions and these are almost always only available over http: https://readlang.uservoice.com/knowledgebase/articles/279539-changing-the-dictionary https://readlang.uservoice.com/knowledgebase/articles/279539...
It worked OK for a short while, but then Chrome and Firefox both refused to display http content within a https page. Chrome displays a very subtle shield icon that the user must click on to reload the page allowing mixed content. This is far too unfriendly to expect my users to do, so I had to resort to using http again :-(
Of course, the ideal solution would be for me to have access to dictionary definitions so I could integrate them properly instead of using an ugly iframe, but with 50+ languages supported, that's a tall order!
- amatix 11y ago> The login request is always sent via https, even when you are using the site over plain http. So your password should always be encrypted. Though it doesn't stop someone (eg. malicious software on a wifi router) altering the login form itself to submit passwords to a different URL...
- VeilEm 11y agoIf a router can change the HTML it can load JavaScript and so it's already game over.
- steveridout 11y agoThat's very true.
- jvdongen 11y agoYou might be able to proxy the dictionaries from your own server? Unless something in the t&c's of the dictionary providers prohibits you from doing that of course.
- steveridout 11y agoI thought about that but don't like the idea: 1. As you say, could be against t&c. 2. Tons of requests for the dictionary page coming from my server's IP address may lead to being blocked. 3. The user can edit the URL template to fetch any site they like, and I don't like the idea of my server fetching content from any arbitrary website. 4. Would add extra bandwidth and load on my server.