I am calling an api with AFNetworking, It is working fine with HTTP request but when I am trying to hit with secure connection HTTPS, it returns the error code -999 "cancelled".
I know there any already many question for this error and it happens with the request is cancelled but my case is different. I am using the same request code for both HTTP and HTTPS.
I tried following things:-
1. Add arbitrary load to true in info.plist
2. Allowed invalid certificate with AFNetworking
Do anyone have any idea about this?
Thanks in advance
Related
I'm working on supporting login by Github OAuth. But I encounter a problem:
When I log in to the Github once, the subsequence OAuth requests will fail with the 302 HTTP status.
When the OAuth request failed, the HTTP request is as follow:
The HTTP response is as follow:
I know the 302 response is caused by the "user_session" in the HTTP request.
My question is that is there any way to disable the user_sesion in the HTTP request. I want to send a totally new HTTP request for each OAuth request.
Thanks!
I tried the solution at Disabling cookies in WKWebView. But it doesn't work for me.
After using
myRequest.httpShouldHandleCookies = false
The WKWebView stops working. I guess it may be caused by the server cannot add cookies to our web browser.
The solution described at https://stackoverflow.com/a/31803708/10399490 works for me.
Just remove the cookies added by the Github.
I haven't verified whether the solution introduces any other side effects
I am using the Alamofire 4.0.1 library in swift 3; I am looking for the HTTP Status-Line (as described in https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html). I can get the status code, the headers, everything, but not the status message.
I am querying a REST API which gives me 403 responses with different messages after the "Forbidden" keyword describing the problem: like the client is not approved for access or that accessing an specific URL is not allowed, because it is for internal use only. In my client accessing the API I want to give the user more details than just the "Forbidden" message.
This is what the server sends back (I know this because I used Paw, a HTTP Client to send a HTTP request and investigate the response):
HTTP/1.0 403 Forbidden (internal method)
So to conclude, is there any chance to get the HTTP Status-Line in Alamofire?
Unfortunately no
Alamofire uses the URLResponse and it does not implement any field/method that gives you information about Status-Line. To get the Status-Line you should use other maybe lower-level frameworks.
URLResponse gives you only information about allHeaderFields, you can look on my answer about it here :
https://stackoverflow.com/a/36524454/5433235
I have an API which validates a user and I don't know what to return to my iOS application when authentication is and isn't successful. I'm currently returning a 401 error for failed authentication, but how should I tell my iOS application that authentication was successful?
You could use an HTTP 200, which indicates the request was OK without problems. You could also potentially use 201 to indicate a new session has been created.
For explanations on HTTP status codes, please see Wikipedia's list of HTTP status codes
I think we just discovered a bug on iOS 9 (version as of Oct 23rd 2015) when using client SSL certs to talk to a backend API. In common with a lot of REST services, our API generates 4xx error codes to communicate status. One of those is a 403 Forbidden error when a client tries to access paths that a specific client ID is not authorized to access. Note that this HTTP error occurs AFTER the client SSL cert has setup a valid connection & and the client ID has been authenticated.
In iOS 9, this sequence will generate an invalid client SSL error:
FAILED: Error Domain=NSURLErrorDomain Code=-1206 "The server “our.server.here” requires a client certificate."
(note: this a followup to my tweet here: https://twitter.com/ckmaresca/status/657576686318256128 - I figured SO is the place most people will search for this)
It took us days to finally figure out but it turns out that this particular error is generated by Apple's new Application Transport Layer security. Specifically, it seems that if you are using client certs and your backend API generates an HTTP 403 error, ATL believes that the cert is bad and kills the entire transaction.
We know this because we can see in our server logs that the request goes through and executes properly. We've also observed that the socket stays alive trough the request and this error only shows up after the response from the server is received. We also know our client cert works since any path not returning a 403 works with zero errors and changing the HTTP error code to 401 makes this problem go away.
This is problematic for a number of reasons, but mostly because HTTP errors are not SSL errors. The two can operate independently and it's perfectly possible to have a 403 error with a valid client side SSL certificate....
The work around is to change all your 403 errors to something else. I would note that a large number of Oauth1/2 servers will generate various 403 errors, so this might be non-trivial. Alternatively, it might be possible to use a reverse proxy to remap HTTP 403 errors to a different HTTP code - we have not tested this.
We have filed a bug with Apple, but I wanted to give people a heads up so maybe they can avoid banging their heads against a wall like we did for a week....
Thanks to the Sherbit.io enginnering team (specifically Varun & Matt) for debugging this.
I keep getting this error when I make a request to an api. The api requires authentication and for this I add valid OAuth token to the header of the request. When I do that I receive a 200 response so all is good.
But I want to test my code to handle a 401 response code. To do this I add a invalid OAuth token to the request. I was expecting the server to just send a 401 response code but instead I got an error from my callback. The error is NSURLErrorDomain Code=-1012, and after looking online it turns out this is a authentication error.
I was expecting the server to just send a 401 back? Instead I'm getting a error in my callback. Is there something wrong with my server or my request?
Thanks for the replies...
I think maybe you need to establish your NSURLConnection with a delegate to handle this the way you want to.
I was using charles proxy and that was the reason I saw this error. When I stopped using the proxy it worked like a charm.
P.s. I've not tested this with NSURLSession but if anyone is curious just add a comment! :)