-
Notifications
You must be signed in to change notification settings - Fork 20
Alternative use of https #343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I don't think that the code requires any changes to support SSL. But the documentation might. Developers might wonder if they should pick HTTP or HTTPS scheme - pros and cons. |
The usage of the SITE_URL setting needs verification. Generally, I think it should reflect the protocol used in the current request, so that any OKAPI links and redirects stay within the same protocol. At first glance I found one minor issue with that: here the protocol in SITE_URL should be replaced by 'http', to be consistent with the installations.xml file. |
Perhaps we need to split it into two dynamically calculated variables - SITE_ID and SITE_HTTPX_URL? At the same time, the SITE_URL settings would be made private to avoid misuse. BTW, I will be offline for the most of the next week. |
Agree. I can do that. I have scanned all direct and indirect uses of SITE_URL and found the following special cases; line numbers refer to ver. 1113: Notice about adding cron5 to the crontab
I think this should show always show http:.... Installations
I think this should always reflecte the site ID, which always starts with 'http:'.
As long as there are no OC nodes which redirect everything to https, I think it is fine to present the site ID here, too. It is unlikely that this situation will change in the upcoming few years. Besides of this, it would be nice if the installations list informs the user if https is available on a site. I suggest to add a new settings value and an installations.xml attribute for this boolean flag. Cache attribution note
There are links to the origin site and to the cache listing. This must not depend on the request's protocol, due to replication. The site ID should do it. Method documentation
A full URL is shown in the docs for each method. I think it should show 'http:...' for non-https-enabled sites, and either 'http[s]:...' or both URLs for https-enabled sites. Site reference in GPX data
I am not sure what to do here. May it confuse client software if it receives changing OC URLs in GPX files? |
Maybe we should right on add a "primary site URL" setting, to get all links independent from the site ID. This would currently be "http:..." for all OC sites but may change to "https:..." if a site decides to do so. This "primary site URL" would be used for
|
I think that we may return HTTPS in many cases, even when the client is making its request with HTTP. This is because - even if the client prefers HTTP over HTTPS - most of the URLs themselves are usually destined to end up in the user's browser location bar, and the browser will handle HTTPS just fine. However, it's hard to discuss cases without the actual code in front of us. :) Perhaps just commit your ideas to a separate branch (in the common repository so that both of us will be able to commit there), and we will set up a chat (or Skype meeting) and talk about it later? |
We will also need to include a new cronjob for verifying server configuration. It will need to verify that OKAPI methods can still be called with OKAPI's base_url and HTTP scheme (if the site responds with a HTTP redirect response, then there's an error and admins need to be notified). [Can I really edit YOUR comments? Wow. -- following5] |
Redirecting an OC site to https is an option which is far in the future, and it looks like it will make the OKAPI implementation too expensive (for me). Another point is that I don't know if the OC.de site will run stable on https right from start and therefor ewill declare https as "experimental". Several issues have already popped up while testing, and more may come after launch (in September?). This said, I would prefer a simple and consistently dual-protocol OKAPI implementation. What about this:
It's up to the maintainer of okapi_settings.php to ensure that these settings correspond to the server's capabilities. OKAPI may verify if the 'https' settings field is consistent with installations.xml. An additional setting PREFERED_SITE_URL will be generated from this information, which will point to https if it is "recommended" and to http else. And then one of SITE_ID, SITE_HTTPX_URL or PREFERED_SITE_URL will be used for all the cases listed above. If you can generally agree to this, I can do a sample implementation. |
Okay, I see your point. Sounds okay! I'm not sure if I understand the difference between SITE_HTTPX_URL and PREFERRED_SITE_URL though. |
Ok, the PREFERRED_SITE_URL ist not needed. Here is the sample implementation, not fully tested: https://github.com/following5/okapi/tree/https The definition of the
Building on this definition, I was able to implement what we had discussed above:
Generally,
I hope that is makes some sense. There is one drawback: Developers have to actively insert 'https' into the URLs to make use of it. If they don't, they will continue with http even if https is desirable and recommended. But I think that returning 'https://...' as installation |
Quite a complex subject! I am preparing my review of your commit, but it comes very slowly. A quick side note: When are you planning on introducing SSL to your site? Have you managed to set up and use HTTPS protocol on the OCPL-DEVEL VM? |
Jep, it's complex. OCDE code had to be adjusted too, and I am doing this without https experience, hoping that it will work out. OC.de will move to a new webhoster soon (October? I thought it would be September, but takes some more time), and we plan to start SSL with the new server. We may start it with declaring OKAPI as non-https if it is not https-ready. There is a (German) Explanation by bohrsty on setting up SSL/https on our old developer VM, which has a customized Apache. mambofive (Elmar) is preparing a new developer VM which will be SSL- and OCPL-enabled, but that may take some more weeks. You may contact him for more information or for assistance in setting up an OC.de devel VM. |
We have now started https operation: https://www.opencaching.de/ |
Totally forgot about this issue. I had unfinished commits in my repository Did you manage to set it up without any changes to OKAPI? On Wed, Dec 23, 2015 at 11:36 AM, following5 notifications@github.com
Tylko niewielu ludzi, którzy cierpią na kaszel, idzie do lekarza. Większość |
Yes, the OC.de https operation is independent from OKAPI. The OKAPI change would just give additional security to OKAPI users. (Also, we currently could not go for "complete SSL security", as OKAPI allows http access to some private data. But we don't consider https-only anyway.) |
Meanwhile, the d6ad7a6 solves this problem for the top-right menu. I am not aware of any other functions which compare the two "site_url" strings. Now OKAPI works pretty well in dual-mode http / https. Before proceeding, OCPL sites should decide how they want to deal with https (opencaching/opencaching-pl#363). |
Won't the users just keep using HTTP, then? They won't even know that HTTPS is supported. BTW: Browsers show warnings when navigating from HTTPS to HTTP, but not the other way around (afair, you can even have HTTPS images embedded on HTTP page without triggering any warnings). If you intend for your users to switch to HTTPS eventually, then isn't it better to return HTTPS links even when OKAPI method is called via HTTP? |
Some developers are already using it. For the other, we can announce it in the OKAPI changelog and blog. Opencaching.de https is still declared "experimental". We will switch to another certificate in a few months, and when that is successfully done we may declare it "recommended".
I would like to leave the choice up to the developers if they use http or https, like other APIs (e.g. Google Maps) do it. There may be applications which are not https-enabled and would break on https links. |
Meanwhile, PL, DE and UK sites are https-only. DE has done this step a week ago, and there are no reports of any broken OKAPI clients. So no need to implement the proposed dual-scheme operation in OKAPI. |
NL and RO will transition towards https as well in the near future. |
Opencaching.de is going to implement secure access. It is planned to enable parallel use of both https://www.opencaching.de and http://www.opencaching.de so that non-SSL-enabled or even non-redirect-enabled clients will not be broken.
OKAPI may be handled independently from this, but it would be nice to have it run with https, too. This would mean that SITE_URL would be set to either of both URLs. At a first glance, it looks like OKAPI can handle this, but I guess that it has not been fully tested in such an environment?
Are there any full URLs including the protocol stored in OKAPI tables or files?
The text was updated successfully, but these errors were encountered: