Supporting https

AusMarkB

We have OI listening on the default port of 80. The port is closed externally because the mobile/web apps actually call via a different port through to a webservices on the same box which then internally redirects to our endpoints.
I asked the other day if we could make our endpoints publically accessible and the basic response was "if we switch you to another port do you support https?"

It's a fair question but I'm a little grey in this area so can anybody tell me if there's anything we would need to do differently to meet this requirement? I feel like there isn't but I can't say categorically one way or the other.

Note, the existing publically accessible mobile/web endpoints do support https already, they're just not our endpoints.

DonBakke

Yes, you can support HTTPS. The good news is that this has nothing really to do with the HTTP Framework. It's all about the configuration of your web server. You said that the same box already receives web service calls through HTTPS but these aren't your endpoints. This suggests to me that the box already has a SSL certificate installed. Even if you have to change actual data to obscure the domain, can you post examples of the other endpoints and your endpoints?

AusMarkB

Thanks Don.
That's pretty much what I was thinking though the person from whom the question came works in this area as a matter of course and for me it's more of an add on so I wondered what I was missing.

I see very little difference.

Theirs	Our equivalent
www.edgecreations.com.au/#/login	edgecreations.com.au/api/login
edgecreations.com.au/#/manager/location/clientid	edgecreations.com.au/api/clients/clientid
edgecreations.com.au/#/manager/location/clientid/shift/shiftid	edgecreations.com.au/api/timecards/shiftid

DonBakke

To be honest, configuring SSL and web servers is not my area of expertise so I will defer to some others on my team to chime in. However, from what I understand, you should already be set up because both endpoints share the same domain. Perhaps there is another setting needed to make this work, but have you actually tried hitting your endpoint with https at the beginning?

JaredBratu

As Don said it should be fairly seamless for your API, the biggest thing you have to worry about is not building a URL that redirects the user back to HTTP using an absolute URL. If your URLs are relative and your server name is correct in the HTTP Framework setup it should use the web servers SSL certificate.

Just to clarify one thing... the theirs/ours equivalent isn't apples to apples. www.edgecreations.com.au/#/login actually points to a page within the JavaScript app on edgecreations.com.au as indicated by the #. The login button on the page actually sends a request to https://edgecreations.com.au/EdgeRESTServices/MainService/Login which would probably be a closer comparison to the edgecreations.com.au/api/login resource. Whoever manages the front end JavaScript application would either need to change it to send the login request to your API OR perhaps the requests are proxied through /EdgeRESTServices/MainService/Login and they would redirect the request to your API at the proxy on the back end. Either way, I don't see a major problem.

Keep in mind though that if they are proxying the requests the IP address of the visitor's request might be the IP address of the PROXY server . If your API isn't concerned with the visitors IP then this won't be an issue.

AusMarkB

within the JavaScript app on edgecreations.com.au as indicated by the #

I was wondering what that was for. The EdgeRESTServices request is actually more familiar to me only because that's the type of request I had noticed being called during testing.

Neither the website nor the mobile app call our API directly though we designed our API with the expectation that they would. They instead call the EdgeRestServices which then manipulates as necessary and then those services call our API on the same box.
There is a webserver with IIS that hosts the EdgeRESTServices. The webserver has a mapped drive to the OI app server and the socketserver is launched on the webserver via the mapped drive.
It has all worked fine so far so we've left well enough alone but now we want to do other things that are independant of the existing web/mobile functionality so we need for our API to be exposed to the internet devoid of the EdgeRestServices intermediary.
I still don't see it as being that difficult but as Don said, it's not my area of expertise either.

Thanks gentlemen for both your input.

DonBakke

We have similar systems in place at different clients. That is, it's the same set of APIs that we publish, but some are indirectly called by 3rd party systems and some are called directly by our own client. Have you attempted to connect to your own APIs directly?

AusMarkB

Hey Don,

No, not recently. They're not exposed so I can't get to them anyway.
That's the point I need to prove before they'll open a port for me.
I can probably get there now I just needed to reinforce my understanding before pushing the point.