I made a home automation controller which embedded a web server inside to let users to control their equipments through web interface and API. I was also making an Apple Watch app since OS1 mainly retrieves user ID and password from iPhone then download a plist from the controller and display the information. I rely on NSURLSession to get the plist through LAN to the controller, however since Watch OS2 NSURLSession only allow https connection that my home automation controller cannot provide. In this case any alternative way to let Apple Watch to get the plist from the controller?
Thanks!
Like iOS 9, watchOS 2 uses App Transport Security to enforce secure connections.
Starting in iOS 9.0 and OS X v10.11, a new security feature called App Transport Security (ATS) is available to apps and is enabled by default. It improves the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based networking requests. Specifically, with ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail.
Since the web server is under your control, the proper approach would be to enable secure HTTPS connections on your server.
If you can't or won't enable that, you could circumvent the security that iOS/watchOS enforces, by adding the appropriate NSAppTransportSecurity keys to your (watchKit extension's) Info.plist.
This would allow an insecure connection from the watch to your server.
Related
We're using AppAuth for a macOS application to authenticate Google accounts. This has been working for years, except recently Chrome has started to block all http connections by default. The loopback server in AppAuth is hard-coded to work with http connections only. The following issue also seems to have gone unanswered: https://github.com/openid/AppAuth-iOS/issues/624
What other options do we have for using a https loopback server on macOS for OAuth2 authentication? We need the loopback server to be able to extract parameters Google sends back after authentication. Asking users to switch from Chrome is not desirable.
Interesting - with loopback desktop logins there are two URLs involved:
The URL in the desktop app, which is meant to be HTTP according to OAuth standards, since it runs on end user PCs. Using HTTPS would require the entire user base to host SSL certificates, which is highly impractical. Typically a loopback URL is a value such as http://localhost:8000, where the port number is often calculated at runtime.
The URL used to invoke the system browser is a value such as https://myauthserver/authorize?client_id=xxx&redirect_uri=http://localhost:8000..., and this should be HTTPS of course.
PROBLEM DIAGNOSIS
I'd be very surprised if Google have blocked this if you are using standard desktop logins, since it has been referenced on their Native Apps Page for years.
Are you sure something else is not the cause? One possibility might be lack of a user gesture in the system browser. Is the problem consistent and are there any differences in these cases:
Make Safari Browser the default before login
Make Chrome Browser the default before login
Make Chrome Browser the default before login and clear browser cache
Let me know and I may be able to suggest some next steps ...
We are calling one API which is based on SSL security (HTTPS) and the SSL certificate is configured on Server side. When we are calling that service from Tizen Web Application in Samsung watch, it’s asking a prompt dialog every time to Allow or Deny with the message “There are problems with security certificate for this site net:: ERR_CERT_AUTHORITY_INVALID“.
Now if we allow the API with SSL security is working fine but the problem is this dialog appears every time when service is going to hit.
Here in the screenshot: X sign means Deny and right side means Allow
Can we have any solution to avoid this Prompt to ask for consuming the HTTPS API call.?
We already configured this below configuration in our Project config.xml file:
<access origin="*" subdomains="true"/>
App: Tizen Web Application
Running on: Samsung Galaxy Watch 3
API: HTTPS with GET method type request
It's an issue of Tizen 5.5.0.2, in the next release of the OS it will be fixed
I am trying to record mobile app with Jmeter, the app has URLs with https,
I am using jmeter 3.1 and configured mobile and machine such that I am able to record URL(both http and HTTPS) and app from mobile in jmeter. Now I have an application, with the same configuration I have tried recording that app, but not able to record anything and the strange thing is that when I am trying to login into the app with proxy in mobile it's says "Unable to connect to server", but without proxy it's logining successfully. Does someone come across this situation. Please let me know if there could be any solution for this.
Unable to connect to server has many faces, going forward include more details into the question, i.e. mobile operating system, proxy configuration details, etc.
In the meantime here is a checklist:
JMeter can record only HTTP and/or HTTPS, other protocols are not supported
You need to configure mobile device to use the host running JMeter as a proxy for both HTTP and HTTPS protocols. For certain operating systems you may need 3rd party software, i.e ProxyDroid in order to setup HTTPS proxy
In case of HTTPS traffic you will need to install JMete's self-signed certificate - ApacheJMeterTemporaryRootCA.crt onto your mobile device. If did it already - be informed that JMeter certificates has limited life span (4 months or something like that) so you need to periodically "refresh" them. The fastest and the easiest way of installing the certificate is sending the aforementioned file to yourself via email and opening the attachment using the mobile device.
See HTTPS recording and certificates chapter of the HTTP(S) Test Script Recorder JMeter User Manual entry for more details.
You can also View the Webcast: Performance Testing for Native Mobile Apps to learn about alternative ways of recording mobile traffic and converting it into a JMeter test.
I have a PhoneGap App running on WP7 that I would like to connect to a Windows Azure Mobile Service. However, in order for this to work in my testing using JSFiddle.net I had to add the JSFiddle domain to the CORS settings in the Windows Azure Mobile Service.
Why do I need to add domains to the CORS setting on the server when doing a simple GET?
Since the Mobile Service requires a key from the JavaScript code I don't see why I cannot open up this web service to any request that supplies the correct key but adding . does not seem to work. If this worked I could move on to testing the scenario on the Phone.
Am I missing something architecturally here or is this just a feature that no-one else is looking for?!
If you want to allow any domain to access your mobile service, you can add the * in the list of cross-origin resource sharing hostnames under the configure tab.
Notice that the application key is not secure. From the 'How to use an HTML/JavaScript client for Windows Azure Mobile Services' tutorial (emphasis mine):
Application key: A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
The takeaway is that you should not count on that key to secure your service.
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.