HTTP access
poke.3712:
Hey, I’m working on integrating some API information on the official wiki, but there is something that prevents me from doing so: The APIs are served via HTTPS, making AJAX requests from the wiki (served via HTTP) impossible.
Would it be possible to also serve the API over HTTP (at least the ones you have right now; I understand that more special ones that might come would somewhat need a secure connection)? Otherwise I will have to create some dummy server that prepares the data, or need to do some server-side wiki stuff.
Cliff Spradlin.3512:
It seems to me like a better option would be to convert the wiki over to HTTPS
.
We want HTTPS Everywhere!
poke.3712:
Well, don’t tell me that ;P But yeah sure, that would be the better option, but I doubt we can manage that in a timely manner…
And I ideally want to integrate the API information… like… now ^^
Crise.9401:
Supporting both protocols would be nice… not everyone wants to invest into a certificate, and self signed certificates in production environments are nasty.
TimeBomb.3427:
I’d also like HTTP access, primarily so we can effectively load the API through the user’s client via JS.
It’d be wonderful if something like this worked with your API (without needing the requester to have an SSL certificate):
http://jsfiddle.net/ksBnt/
What is the reason behind needing a public API to be secured via SSL?
rhoot.5927:
The problem is with the Cross-Origin Policy and would affect you regardless of allowing HTTP. What needs to be supported is CORS: https://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
poke.3712:
Okay, alternate plan: Can you set a CORS header on the API server? I.e. send the following header for the public endpoints:
Access-Control-Allow-Origin: *
Talis.7261:
Okay, alternate plan: Can you set a CORS header on the API server? I.e. send the following header for the public endpoints:
Access-Control-Allow-Origin: *
I had this thought too.
I think my requests are not working due to the same-origin policy. I may be wrong, but apparently, my browser does not allow the request because it is using a different domain.
In order for this to be allowed, I think that the API servers would have to allow any origin in their response headers.
Crise.9401:
CORS is not supported universally though, while allowing both protocols and/or using JSONP can work for wider array of clients.
rhoot.5927:
It’s not, but it’s supported by enough browsers that it would definitely be worth using: http://caniuse.com/#feat=cors
Edit: Regardless, it was just activated!
Cliff Spradlin.3512:
We’ve added support for CORS to solve this problem. Please refer to the API Changes thread for more information. We don’t plan to add support for JSONP at this time — we consider it obsolete now that CORS exists.
Talis.7261:
Thanks for the quick fix!
poke.3712:
Thanks a lot, and the feature is already live on the wiki! Any event page now allows quickly fetching its status.
Crise.9401:
It’s not, but it’s supported by enough browsers that it would definitely be worth using: http://caniuse.com/#feat=cors
Edit: Regardless, it was just activated!
It is worth using, but why exclude JSONP, when it can be in there parallel… through an argument (ie. jQuery style).
JSONP may be “obsolete” but CORS hardly fully adopted yet either…
Edit: in particular of course I am talking about microsoft, as usual, anything older than IE 10 does not support CORS through standard XMLHttpRequest and using the alternative has some complications.
Also, I haven’t checked recently but jQuery didn’t make use of alternative solution for IE either when I last checked (update: jQuery relies internally on XMLHttpRequest, so yeah with jQuery anything older than IE 10 does not support CORS).
TimeBomb.3427:
We’ve added support for CORS to solve this problem. Please refer to the API Changes thread for more information. We don’t plan to add support for JSONP at this time — we consider it obsolete now that CORS exists.
Beautiful. Thank you so much for the quick and effective fix, it’s highly appreciated!
Varonth.5830:
It seems to me like a better option would be to convert the wiki over to HTTPS
We want HTTPS Everywhere!
That may be nice, but it can also make other things more complicated than they should be. For example trying to fetch the JSON strings with a Java program. Welcome javax.net.ssl.SSLHandshakeException …
Installing certificates is quite the pain in java, especially if the program should be available to the public.
The Talcmaster.7391:
Yeah, I already ran into that. I use something called InstallCert. This little program will make a keystore with the certs of a given webaddress. It’s all over the web since it has been around a long time. Here’s one precompiled version I was able to find: http://www.opentox.org/tutorials/q-edit/how-to-install-ssl-certificates
Varonth.5830:
Yeah, I already ran into that. I use something called InstallCert. This little program will make a keystore with the certs of a given webaddress. It’s all over the web since it has been around a long time. Here’s one precompiled version I was able to find: http://www.opentox.org/tutorials/q-edit/how-to-install-ssl-certificates
It’s also not that hard to do via CLT. It’s just that you will have a hard time giving away your program, when it requires either a 3rd party program on top of that, a manual installation by the user (with the 3rd party program or per commandline), or an automated script to do this for you (which might aswell fail, in case someone is using a different password than the standard one).
Java is meant to be easy to setup, while giving the user a somewhat save environment. He can be pretty sure that there is no keylogger in it, when there is no .dll or .exe just as an example (unless of course it is starting to download those via the Java program itself, but I think you get the point).
The Talcmaster.7391:
Yes, I suppose that is a concern if you are planning on handing the user a desktop application. I believe it is possible to specify the file that is supposed to act as the keystore in the program itself (never done it myself but I’ve seen applications do things like that) so you could probably just package it in the jar files or what have you.
Varonth.5830:
Yes, I suppose that is a concern if you are planning on handing the user a desktop application. I believe it is possible to specify the file that is supposed to act as the keystore in the program itself (never done it myself but I’ve seen applications do things like that) so you could probably just package it in the jar files or what have you.
While this is possible, why would you want to do this? You would either have to include the certificate, or download it during runtime (which would on the otherhand completely bypass the security aspect of SSL).
The first idea on the otherhand adds another layer of maintenance needed, as the certificates might change in the future (shouldn’t be a common issue, but might happen). In that case you would have to make a new version.
Besides it requires alot more work on the clientside to set everything up.
And what exactly do we accomplish? We secure the transfer of data like, event ids, item descriptions etc.
It’s not like we are transmitting personalised data or something.
I could understand if we get personal data, like character informations etc.
Those would atleast make a bit of sense to submit via SSL.
But in that case we would probably also need tokens for different aspects (like Eve have multiple API tokens).
The user then has a keytoken for the public API, which will be used for public informations like the current event, wvw, item and recipe informations, and whatever else comes.
Then they also have a private keytoken, which allows them to fetch character informations etc.
Perhaps they could add a third type, which would be kinda like a limited private keytoken, which just includes certain private data, for example account and character names and classes. These could be useful for LFG sites for example, to add a list of characters available if someones is looking for a group etc.
The private keytoken on the other hand could also include equipment and bank informations for example (this might have an application in case a guild wants to have a member overview etc…).
But the current API we have is secure for no reason I can see.
Even if you are going to communicate with the wrong server in case of HTTP, what is the worse that can happen? Fetching wrong item descriptions?
Stumpzy.8527:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Servlet issues via https
Varonth.5830:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Servlet issues via https
Jep, same issue I am running in.
You will have to make your own KeyStore instance, which will load the Certificate needed to establish the SSL connection to the ArenaNet servers.
The default Java Keystore does not include the root certificate of StartCom Ltd. which was used to sign the certificates of ArenaNet.
You shouldn’t try to modify the default KeyStore during runtime, as that one is password protected. It has a default password ‘changeit’ but the user might have altered this.
So one possibility would be to create an empty KeyStore instance, and just load in that single certificate you want to use. Then establish a SSL connection just this KeyStore instance instead of the default one. Of course, if you then want to use this SSL connection object, whichever it might be, for another SSL connection to a different server, you will have to set the default keystore again…
Here is an example how to add a key during runtime to the default KeyStore. You should be able to get the information needed to setup a new KeyStore instance from this: http://stackoverflow.com/questions/10077714/adding-certificate-to-keystore-using-java-code
Didn’t test it though.
Just tested this one:
http://www.rgagnon.com/javadetails/java-fix-certificate-problem-in-HTTPS .html
(sorry cannot post the URL as the forum filter will kitten it :P )
Yes it works, and you can basically just copy and paste it in whatever code you want.
What it will do is, accept whatever certificate the server uses. It does no check whatsoever. Not what SSL is intended to do, but it gets the job done.
But it could aswell be a HTTP connection (which it probably should be :P )
Cliff Spradlin.3512:
We’re not planning to allow HTTP access to the API. This is for both practical and philosophical reasons.
Yes, the APIs available now are freely accessible, but authenticated APIs in the future will require encryption as part of their security architecture. All of our current web sites and web services require HTTPS, and this API will be no different.
Please do not disable HTTPS certificate validation to work around certificate errors.
It sounds like Oracle is not including our certificate issuer’s root certificate into Java by default. We’re talking to our issuer to see if we have any options.
The right solution for now for Java programmers is probably to embed the root certificate for api.guildwars2.com into Java applications dynamically.
I’d appreciate it if a Java developer here could post steps on how to do that so that others can work around this issue safely for now.
Charles Peter Nystrom.5923:
I hate to point others to outside sources for this instead of providing a concrete example, but the best explanation of the process and potential pitfalls for loading certificates from jar resources that I have found are:
http://www.mayrhofer.eu.org/create-x509-certs-in-java
(Sorry for bumping an older thread, I believe this is still relevant)
zwei.9073:
I’d appreciate it if a Java developer here could post steps on how to do that so that others can work around this issue safely for now.
This class contains example of certificate initialization:
https://code.google.com/p/gw2api/source/browse/trunk/src/cz/zweistein/gw2/api/dao/OnlineJsonDao.java
Using file with certificate instead of byte array is matter of taste, but i am assuming that root certificate authority is not going to change anytime soon.
Cliff Spradlin.3512:
Hi,
We’re rolling out an experimental new SSL certificate for api.guildwars2.com. Hopefully the new certificate will resolve the certificate verification issues that developers have been experiencing on some platforms.
There’s a DNS change involved, so it unfortunately won’t be an instant transition.
Please reply if you have any trouble with or comments about the new certificate.
Thanks!
Yamagawa.5941:
So either the key I had expired, I’m waiting on DNS, or your move to a new key broke my impl.. which was admittedly ad-hoc to start with. shrug
Gives me something to bang on for a bit, as I do need to understand it better.
Yamagawa.5941:
Hum, my browser can get into the API, but I’ve not had luck copying keys out to make it work, which is what I did the first time around… SSL is a weak point for me. I can see that it’s broke, but can’t say how or why.
//Yamagawa
Rurik Telmonkin.3648:
Can someone inform those of us less intelligible about SSL certs how to get the new certificate that we need for this? Java users especially will be having lots of trouble now due to Java not automatically including startcom’s certificates.
Yamagawa.5941:
Oooh, sneaky with an extra layer of sneak on top.
To access the API, looks like I get by with just:
connection.setSSLSocketFactory(SSLContext.getDefault().getSocketFactory());
To access the TP however, that’s not working for me. May be that I need to use the old key. May be that I need to do something else, but I gotta duck out for work.
//Yamagawa
Cliff Spradlin.3512:
Can someone inform those of us less intelligible about SSL certs how to get the new certificate that we need for this? Java users especially will be having lots of trouble now due to Java not automatically including startcom’s certificates.
Hi,
I wasn’t very clear about this earlier. The new certificate has a different root (GeoTrust) which is included by default in Java’s certificate store. With the new certificate, you should be able to remove all the weird manual cert stuff you’re doing in java, because a normal connection to the API should just work.
Yamagawa.5941:
Hi,
I wasn’t very clear about this earlier. The new certificate has a different root (GeoTrust) which is included by default in Java’s certificate store. With the new certificate, you should be able to remove all the weird manual cert stuff you’re doing in java, because a normal connection to the API should just work.
And the change breaks the wierd manual cert stuff (why it’s sneaky). The TP isn’t using the same thing (extra sneak), so one-size-fits-all code won’t work to simultaneously access both.
No worries, just give us a description next time and us users won’t need to panic so much. I approve of this change, just had problems feeling it out absent any details.
//Yamagawa
Rurik Telmonkin.3648:
Can someone inform those of us less intelligible about SSL certs how to get the new certificate that we need for this? Java users especially will be having lots of trouble now due to Java not automatically including startcom’s certificates.
Hi,
I wasn’t very clear about this earlier. The new certificate has a different root (GeoTrust) which is included by default in Java’s certificate store. With the new certificate, you should be able to remove all the weird manual cert stuff you’re doing in java, because a normal connection to the API should just work.
Thanks Cliff, will give it a go later today.