Sup dudes,
Working on creating a Bing Image Search API for Swift. My problem is that my app key contains '+' and '/' so when I make a request, I'm getting back because it seems that it treats '+' and '/' as spaces. It should treat everything before the query as a regular character, right?
Any idea how to fix this request so it doesn't screw up my AppID?
App ID Example:
"aaaaaa/aaaaaa+baaaaa/asdf="
Response (Formatting is off, but it is in fact a space between the a's)
{"SearchResponse":{"Version":"2.2","Query":{"SearchTerms":"sushi"},"Errors":
[{"Code":1002,"Message":"Parameter has invalid
value.","Parameter":"SearchRequest.AppId","Value":"aaaaaa\u002faaaaaa
baaaaa\u002fasdf\u003d","HelpUrl":"http\u003a\u002f\u002fmsdn.microsoft.com\u002fen-
us\u002flibrary\u002fdd251042.aspx"}]}}
Code for get request (works perfectly):
let url = NSURL(string: "http://api.bing.net/json.aspx?Appid="+AccountKey+"&query="+query+"&sources=Image");
let task = NSURLSession.sharedSession().dataTaskWithURL(url) {(data, response, error) in
println(NSString(data: data, encoding: NSUTF8StringEncoding))
}
task.resume()
Forgot to mention, I got frustrated and tried it out in C# and it works flawlessly. New to Swift (obviously)
Edit: Added URL string to Get Request code sample above.
Related
I have an iOS app which sends a HTTP request for the login to our Webserver. The login basically works fine, but as soon as someone got a '€' in his password the login fails.
This bug only happens in the app. We also have a web application, which sends the same login request to the same webserver and I can perfectly log in when I do that in my browser, even if there is a '€' in my password.
Here's the function that generates the request:
func SignOn() {
var request = Helper.getURLRequest(str: str, method: "POST")
guard let httpBody = try? JSONEncoder().encode(Helper.Logon.init(domain: String(userDomain[0]), user: String(userDomain[1]), p: ""))else { return }
request.httpBody = httpBody
let urlSession = URLSession(configuration: .default, delegate: self, delegateQueue: nil)
urlSession.dataTask(with: request) { (data, response, error) in
do {
guard let data = data else { throw Helper.MyError.NoConnection }
Helper.isAuthenticated = try JSONDecoder().decode(Helper.Authentication.self, from: data)
task.leave()
} catch {
[...]
}
static func getURLRequest(str: String, method: String) -> URLRequest {
let url = URL(string: str)
var request = URLRequest(url: url!)
let loginString = "\(Helper.loggedOnUserWithDomain):\(Helper.loggedOnUserPassword)"
let loginData = loginString.data(using: String.Encoding.utf8)
let base64LoginString = loginData!.base64EncodedString()
request.setValue("Basic \(base64LoginString)", forHTTPHeaderField: "Authorization")
request.httpMethod = method
request.setValue("application/json; charset=UTF-8", forHTTPHeaderField: "Content-Type")
return request
}
SignOn() gets called as soon as the user presses the "login" button in the app. Username and password are stored in two variables in my Helper class.
SignOn() will then call a function that generates the request - also in my Helper class.
I double checked every step in getURLRequest(). loginString and loginData both keep the € and they are perfectly displaying the character when I let Xcode print the variables.
I then checked the base64 string. Let's say someone enters "t€stpassword". The encoded base64 string should be VOKCrHN0cGFzc3dvcmQ=, which the function got right. I then let the function decode the base64 string again and checked if "t€stpassword" was the result, which again was true.
Then I checked the request with HTTP interception, but it also had the '€' in his body.
I already tried to percent escape the '€' character but that does also not work. The '€' gets percent escaped correctly, but I think the web server can't handle it then, I don't really know tbh. I used this method: how to http post special chars in swift
I'm out of ideas what I'm doing wrong here. I'm pretty new to Swift so I don't want to rule out, that I'm missing something obvious. Could the web server be the issue? But as I said, the login is working when doing it in a browser, so the server cannot be the issue, right?
According "The 'Basic' HTTP Authentication Scheme" in RFC 7617, section 3:
3. Internationalization Consideration
User-ids or passwords containing characters outside the US-ASCII
character repertoire will cause interoperability issues, unless both
communication partners agree on what character encoding scheme is to
be used. Servers can use the new 'charset' parameter (Section 2.1)
to indicate a preference of "UTF-8", increasing the probability that
clients will switch to that encoding.
Furthermore,
For the user-id, recipients MUST support all characters defined in
the "UsernameCasePreserved" profile defined in Section 3.3 of
RFC7613, with the exception of the colon (":") character.
For the password, recipients MUST support all characters defined in
the "OpaqueString" profile defined in Section 4.2 of RFC7613.
The "recipient" here is the backend. The referenced RFCs in the cited paragraphs clearly describe how the backend should process the Unicode characters and how to perform the comparison operator. You might test the server against the specification to figure out whether the server behaves correctly.
The client however, should at least check for a semicolen in either the password or user-id which would be an invalid credential for Basic HTTP Authentication.
So, your code should work, unless the backend does not want to handle Unicode. If this is the case, only allow ASCII on the client side.
When the authentication fails, a server might message the expected charset in the response in the Authenticate header:
WWW-Authenticate: Basic realm="foo", charset="UTF-8"
However, specifying a charset parameter is "purely advisory". We can't rely on the server sending this.
Basic HTTP is what the name suggests: a basic authentication scheme. It has been deprecated for a while now.
If possible, use a more secure and a more resilient authentication scheme.
I have a linux based node.js server running on BlueHost that I have configured to respond to basic GET and POST requests. I have tested these requests extensively in Postman and they all seem to work great. I figured the transition to doing these requests from an app would not be too difficult but I am currently unable to get either of them to work.
I am using boilerplate code based on this repository. As an example here is the code I am using for the get request
guard let url = URL(string: "publicIP/test") else { print("Invalid url"); return }
let session = URLSession.shared
session.dataTask(with: url) { (data, response, error) in
if let res = response {
print(res)
}
if let d = data {
print(d)
do {
let json = try JSONSerialization.jsonObject(with: d, options: [])
print(json)
} catch {
print(error)
print("ERRORED")
}
}
}.resume()
This code works great for the https://jsonplaceholder.typicode.com/users endpoint however whenever I try substituting it with my public ip (just like in Postman) and I keep getting the following error.
2018-02-18 01:14:35.633518-0800 Application[1248:321560] Task <2E64810D-C10E-4D45-82F5-9C9E37A5FE54>.<1> finished with error - code: -1002
Keep in mind this information is not passed throughout the error parameter as "ERRORED" is not printed.
Can you add this to your info.plist
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
That error should not be related to using HTTP instead of HTTPS. App Transport Security failures return error code -1022.
The error code -1002 indicates an invalid URL. Perhaps your HTTP file contains a structurally invalid URL (e.g. missing scheme, a scheme other than http/https, etc.)?
For additional debugging, set this environment variable
CFNETWORK_DIAGNOSTICS=1
in your Xcode project and re-run the app. Once you know what URL is failing, the problem will likely become more obvious.
If it isn't, file a bug.
You can check the list of error code on below link
Apple Documentation NSURLErrorDomain Error Codes List
The issue was not any of the example code but merely a misunderstanding of what a url string should look like. I figured that I would need to match the url of the webpage as shown in the address bar of my web-browser but that is not exactly true because http does not show even if it is a part of the address in chrome.
The solution was simply to prepend http:// to the front of my url.
I use Alamofire 4.5.1 to download some mp3 files.
If I provide incorrect URL or the request can't be authorised I get an error with 4xx status code (as it is supposed to be) and in my particular case xml with the error explanation.
The issue is that Alamofire saves the error xml response to my destination url, which looks like: .../my-sound-file.mp3
In other place in my app, which is decoupled from downloading code, I might later check if I have .../my-sound-file.mp3 on disk and try to play it, which obviously fails since my sound file is actually xml file with mp3 extension.
Is there a nicer way to prevent Alamofire saving an error data as an originally requested file?
The code I use (with my crude solution to this issue):
let destination: DownloadRequest.DownloadFileDestination = ...
let request = self.sessionManager.download(url, to: destination)
request.validate()
request.response { response in
if response.error == nil {
// do some stuff
} else {
// So far I am forced to manually remove file in case of error
try? FileManager.default.removeItem(at: destURL)
// propagate error
}
}
I stumbled upon this because I assumed that if a request validation fails the destination URL should be empty.
I think I am not the only one with this assumption: Alamofire: file download and validation failure
Personally, I delete the file in case of error. Just as you propose.
I am making a simple request to the Flickr API. I know that the request URL is correct and that the URL task returns data. However, when I try:
let jsonObject: AnyObject! = try NSJSONSerialization.JSONObjectWithData(data, options: [])
in a do, catch block, the operation fails but doesn't crash the app. I have tried changing the options to MutableContainers and AllowFragments but nothing seems to work.
Take the data and convert it to a string like this:
let responseString = String(data: data, encoding: NSUTF8StringEncoding)
Then paste that through a validator like jsonlint.com to see if you're actually getting valid JSON.
I suspect you aren't getting a valid HTTP response from the API, and so maybe you're getting HTML back (or plain text) that describes the error?
So I'm sending a basic auth request to Bing Image Search to grab some image data, and it was working great, right until I updated to the latest version of Alamofire (1.3 -> 2.0.2), which I had to do because 1.3 wasn't even close to compatible with XCode 7.
Anyway, here is my code:
let credentials = ":\(Settings.bingApiKey)"
let plainText = credentials.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
let base64 = plainText!.base64EncodedStringWithOptions(NSDataBase64EncodingOptions(rawValue: 0))
manager = Alamofire.Manager.sharedInstance
manager!.session.configuration.HTTPAdditionalHeaders = [
"Authorization": "Basic \(base64)"
]
let url = NSURL(string: Settings.bingImageApi + "&Query=" + keyword + "&$top=15&$skip=" + String(skip))!
manager!
.request(.POST, url, parameters: nil, encoding: .JSON)
.responseJSON { request, response, result in
...
And I'm getting the error:
FAILURE: Error Domain=NSCocoaErrorDomain Code=3840 "Invalid value around character 0." UserInfo={NSDebugDescription=Invalid value around character 0.}
The authorization type you provided is not supported. Only Basic and OAuth are supported
I had the same issue while moving from Alamofire 1.x to 2.x.
One workaround I found (and that works), is to pass the headers when performing the request:
let headers = ["Authorization": "Basic \(base64)"]
Alamofire.request(.POST, url, parameters: nil, encoding: .JSON, headers: headers)
For more information you can take a look at the documentation.
please read here http://ste.vn/2015/06/10/configuring-app-transport-security-ios-9-osx-10-11/
"App Transport Security (ATS) lets an app add a declaration to its Info.plist file that specifies the domains with which it needs secure communication. ATS prevents accidental disclosure, provides secure default behavior, and is easy to adopt. You should adopt ATS as soon as possible, regardless of whether you’re creating a new app or updating an existing one."
The first part of the error is due to you not receiving valid JSON in the response. You can use response, responseData or responseString to help debug.
The second part of the error is due to how you are setting the header. You cannot set an Authorization header after the session configuration has been created. You can either create your own session configuration and your own Manager, or you can pass the Authorization header in the request.