I am using NSURLSession to implement an osx application that perform REST requests, and has the ability of manually or automatically configure proxy settings for app requests.
I was able to do this using session configuration, and is working for simple contexts.
However when it comes to proxies that require authentication I encounter some issues.
Due to some project requirements, when a request fails due to proxy authentication error(status code 407), I need to display my own custom dialog.
From what I've read so far, I did not find any way of achieving this using NSURLSession. There are some delegate methods related to authentication challenge, but are called after the challenge was already displayed to the user.
Is there a way to skip showing an authentication challenge for a NSURLSession request and fail with 407 status code instead?
As far as I know, neither NSURLConnection nor NSURLSession ask the app to handle 407 responses before displaying that dialog, and there's not a way to change that, short of filing a bug with Apple and convincing them to add that functionality in a future version of iOS or OS X.
For now, I think the best you can probably do is use libcurl to make a "junk" request first, see if it returns a 407, and if so, ask the user to provide new credentials. It isn't pretty, but it will technically meet your requirements. :-)
But honestly, the requirements are dubious. OS X and iOS users don't expect to control proxy settings within an app. They're normally systemwide behaviors. As such, trying to control them in the app is questionable. So if you have any say-so in the matter, you should try to get the requirements changed.
Related
For the first time, we are developing a new project that needs to support the browser (a website) and a mobile app built on react-native.
We have plenty of experience developing for the web, but little to no experience in the mobile app world.
We are now defining our API and trying to make it work for both platforms - This will be a basic JSON API, running on Flask. The API will have some public endpoints, and some protected ones as well (that require auth). We want a cross platform auth solution.
Typically, for the web, we have always relied on cookie based sessions (encrypted) that frameworks like Flask provide. We have been successfully using these in various scenarios: loading HTML templates directly from the web framework, or even when the frontend application runs on React (same domain + HttpOnly + secure cookies).
The introduction of react-native could potentially bring some new challenges, and some of our developers worry about not being able to continue to use our typical session based cookies - They are advocating to using something like JWT for authorization, for both the browser and app (and yes, I know that we can't compare sessions to token based auth).
I'm not a big fan of token based authorization (for a number of reasons, could entertain that conversation if anyone wants to waste some time...), and I can't seem to understand why we shouldn't stick to our normal encrypted "Cookie" value.
Here is how I imagine this could work, based on using the Flask cookie session:
A user hits /api/login with some credentials
The endpoint will validate the user and return back whatever response + the Set-Cookie header with a value of session=<encrypted string>
Any further requests from the browser/app would send back the cookie value again.
Essentially, nothing would change for typical browser implementations, this is how browsers work by default.
The react-native documentation mentions a few issues with cookie based authentication: https://reactnative.dev/docs/network#known-issues-with-fetch-and-cookie-based-authentication
From what I can gather (my knowledge is extremely limited on this subject), react-native might not always respect the Set-Cookie header. Which is OK - we would just have to make sure to send back the expected header with any further requests.
This, in theory, would fulfil our requirements.
I'm looking for feedback on my "solution", am I missing anything? Did I get HTTP completely wrong?
React Native actually provides networking similar to that of websites developed with basic JavaScript, which also supports cookie based authentication, however there are some serious caveats as mentioned in here
The following options are currently not working with fetch
redirect:manual
credentials:omit
Having same name headers on Android will result in only the latest one being present. A temporary solution can be found here:
https://github.com/facebook/react-native/issues/18837#issuecomment-398779994.
Cookie based authentication is currently unstable. You can view some of the issues raised here:
https://github.com/facebook/react-native/issues/23185
As a minimum on iOS, when redirected through a 302, if a Set-Cookie header is present, the cookie is not set properly. Since the redirect
cannot be handled manually this might cause a scenario where infinite
requests occur if the redirect is the result of an expired session.
Therefore, I would advise against using it as it is unstable and might give you a hard time dealing with it
I also suggest looking into frameworks that handle authentication for you, such as auth0
Hope you find this helpful :)
i have a scenario running with an own CALDAV-server and CALDAV-clients like (iOS-calendar, mac-Calendar, Android sync adapter, Thunderbird/Lightning, Outlook Sync, ...)
The authentication so far works via basic auth (https and the "Authentication"-Header).
The CALDAV-clients store the user/password in their configuration.
So far so good, but the issue comes now once the password of the user/account either gets changed, reset, expired, etc.
The server has a restrictive password policy enforced, which locks the account after x failed attempts (e.g. 10).
What is happening now obviously is, that once the CALDAV-client configuration was not updated it continues to use an old password.
The server responds with an 401 not authorized - ok, thats fine apparently again.
But the Clients still continue to use the outdated password. It would be nicer to stop polling and present the user with a dialog that his credentials are not valid anymore. But the clients are out of my control so nothing can be directly done here.
The result: after 2-3 iterations (as most clients tries multiple request in one sync iteration) the account on the server of the user is locked due to too many failed login attempts.
That is not nice. The issue seems to be generic and known as "stale passwords".
A solution could only be a better client handling (out of scope here) or a oAuth-token handling. But i was not able to find anything that standard CALDAV-clients supports this. Only google calendar seems to enforce an oAuth2 authorization before allowing CALDAV communication.
So the question is, is there a good way to improve the bad experience of locked accounts?
Some special 401 response which tells the clients to forget the password or not using it again?
constructive feedback highly welcome.
Edit:
for macOS and ios calendar i found a strange behavior (bug) causing and/or enforcing the described situation.
A standard 401 response will cause the clients to bring up the password dialog as expected and described above. The clients stop polling until a new password is entered - as desired.
In my case the 401 response body contained an inline base 64 image (img src="data..."):
This doesnt lead to a password renewal dialog! Just a "something goes wrong" error state.
The clients are continuing to poll! Locking the accounts after some tries ;(
A solution for this problem than will be to remove the inline image but for me it sounds like a bug that an inline image in the 401 response provokes a different behavior on the client.
Some special 401 response which tells the clients to forget the password or not using it again?
Well, 401 is that response. If the client receives a 401 it knows the the login/password combination it provided doesn't work anymore, and shouldn't retry with the same. Obviously the clients don't do this, partially because:
On the other side your servers x-failed-attempts locking doesn't work with stateless protocols for obvious reasons. HTTP doesn't have that feature builtin. Locking the account is a side effect a client doesn't have to expect when running idempotent HTTP requests.
Assume the client is downloading 10 batches of items concurrently. If the credentials invalidate during this, the account would immediately be locked :-)
Summary: You can't use basic auth naively with backends that lock accounts after n-tries.
Google and iCloud both use token based auth schemes (Google OAuth, iCloud a proprietary one). You can't expect those to work in other clients. E.g. while the Apple clients support OAuth for Google, I don't think they support that for other account types.
So what can you do
I'm reading your question so that you own the account server and that the account locking is intentional and desired. (I.e. it is not a side effect of a different (e.g. SSO) backend system you reach out to.)
I think in this case it should be reasonable to rework your account system to allow unlimited login attempts with just the old password.
The lock-after-n-attempts measure is to protect against people trying different passwords. In your case it is always the same and as a bonus it also matches the old password.
There are a lot of different variations of this approach.
Is there any way i can suppress this implicit authentication dialogue ?
I am getting this dialogue before my didRecieveAuthenticationChallenge function is being called.
What I am not able to understand is why this dialogue is in place if i have handling authentication on my own.
I am returning YES from canAuthenticateAgainstProtectionSpace method.
But the dialogue appears prior to hit that
OS X and iOS call your app's handler only for challenges that provide a WWW-Authenticate header. Typically, a proxy challenge provides a 407 response with a Proxy-Authenticate header, which is not treated as a challenge that an app can respond to.
If you know the credentials for the proxy somehow, you can pre-populate the user's keychain with those credentials, and the OS will automatically use them.
If you're in control over the proxy, you can make it send a 401, and the OS will pass that through to your client. Alternatively, in iOS 9 and OS X v10.11, you might be able to take advantage of the network extension stuff to control the proxy, but that is generally only appropriate if the purpose of your app is to control some hardware that acts as a proxy, and I haven't looked at those aspects of NE to know whether it even provides that level of control.
Otherwise, the OS is behaving as expected, and there's not much you can do about it other than to file a bug asking for a new authentication challenge type for proxy authentication.
I am developing a REST API, and have found a very interesting problem.
When I access the resources in a web browser (in my case Chrome), everything works fine. However, when I access the resources using a REST client (Google Chrome plugin, web-based client, and a Java applet), NONE of the variables pass to the API. This happens both with GET and POST methods.
I have absolutely no idea why this would be the case, and it's proving very difficult to test the methods before putting them into production (especially with POST methods).
Please help!
At first glance it sounds it could be 2 things:
You are not correctly passing API parameters via your client or
applet
A problem with authentication or cookie management. Does the API require any type of authorization?
Are you forgetting to set a necessary HTTP header?
Do you have control of the API also or is it a third party API? If so, do the params arrive at all or do they arrive empty? What's the error code? - a 403 not authorized (which would make sense if the key doesn't pass) or something else due to missing params.
Try the intermediate step of doing it with CURL form the command line - that'll give you more detail on what's coming back.
This is probably a related question, except it's in Android: How to check WiFi is pass through web page login?
Anyway, my issue is that I need to detect whether the user on my WP7 app is connecting to an access point that requires web authentication. The access point would not provide any Internet connectivity if the user has not authenticated himself.
Is there any way I can detect such a situation? Or perhaps redirecting the user to the access point's authentication webpage before proceeding with the app flow would be nice too!
I'm currently using WCF Data Services btw.
Easy: just make a WebRequest for a url that you know that always return the HTTP response code 200 (the OK code) and if it returns any 30x that will be the router redirecting you elsewhere!
Example: requesting http://www.whatismyip.org/ should return HTTP response code 200!
There is currently no way to detect this.
What I did was to make a HttpWebRequest to the service, and see if it starts off with xmlns using the .Contains() method. If the call is redirected to the WiFi hotspot, then it will return a HTTP response, which is inherently different in nature.
I know this might not be the best of solutions, but it works for me to simply test reachability.