Set different User-Agents for multiple UIWebViews - ios

My app has UIWebViews, some loading sites where I need the desktop version of the site, some loading sites where I need the mobile version of the site.
So I set the user-agent to a desktop user-agent or a mobile user-agent to achieve this.
For example if I want a UIWebView to load a site's Desktop version I will simply run this code right before:
NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:#"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36", #"UserAgent", nil];
[[NSUserDefaults standardUserDefaults] registerDefaults:dictionary];
The problem is that this of course is setting a NSUserDefaults variable, meaning for any UIWebView in my app that loads after this it will use the desktop user agent. I can just flip flop the NSUserAgent as needed between desktop and mobile and load accordingly but sometimes my app requires TWO UIWebViews to load at the same time, one mobile, one desktop.
Is there any way I can set the user-agent of a UIWebView specific to said UIWebView?
I'm assuming this is going to involve swizzling NSUrlRequest methods or something? I know very little about that stuff

The easy way, if possible, is to just use WKWebView instead of UIWebView. WKWebView exposes the user agent string as a property on the class itself (.customUserAgent, iOS9+). As an added bonus, JavaScript code running in the view will be faster and will use less battery power because the JavaScript can be precompiled into native code.
That said, if you have to stick with UIWebView for some reason, you could create an NSURLProtocol that intercepts all your app's HTTP requests and changes the field depending on the hostname in the URL. There are some examples of an NSURLProtocol on Apple's website. Start with that and tweak as needed.

Related

Changing UserAgent of WKWebView after webView has loaded

Previous Title: Completely restarting a WKWebView after runtime
I am trying to implement a feature that allows for the user to request a desktop site of a URL in the WKWebView. If I'm not mistaken, this can only be done by resetting the UserAgent programatically, and then restarting (not sure what the correct term to use here is) the UIWebView altogether.
The UIWebView is setup in the Interface Builder and connected through an IBOutlet. Does anyone know where I would start? I am trying to implement this into a function.
Alright, so I figured out the simple answer to my question after a bit of debugging. You can literally set the custom user agent and reload the web page. Extremely simple. Here's some sample code via a function:
func requestDesktop() {
// Set Desktop UserAgent
let desktopAgent: String! = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12"
webView.customUserAgent = desktopAgent
webView.reload()
}

How to fix a "403 - disallowed_useragent" with the native Google Drive iOS SDK?

I'm following the instructions given at: https://developers.google.com/drive/ios/quickstart?ver=swift.
Yesterday it was working but this morning it seems to always fail. The weird part is that I'm using their native SDK. I don't know why does it believe I'm using a web-view. The exact error is:
This user-agent is not permitted to make an OAuth authorization request to Google as it is classified as an embedded user-agent (also known as a web-view). Per our policy, only browser are permitted to make authorization requests to Google. We offer several libraries and samples for native apps to perform authorization request in the browser.
I cloned: https://github.com/googledrive/ios-quickeditor and got the same error.
try this, it will works for
"Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36"
Google restrict the authentication from webviews. it's accepting safari webkit useragent .override useragent with above useragent string it will works.
Here is the unfortunate answer: Yes, you are using the example from Google's iOS Quickstart, the "native SDK" as you call it. That's outdated, however, as it uses exactly the embedded web view that Google doesn't want you to use anymore.
If it did work before, but has stopped doing so all of a sudden (like I experienced myself), it may have to do with you changing something related to the client ID. For client IDs that exist for some time, there seems to be a longer grace period until Google hard-blocks the web view use (there should still be just some warning for now, I understand). A new client ID I created recently for unrelated reasons, seems to have caused just that, getting me stuck in having to replace Google Drive authentication code for a new release at short notice.
As to the options (that the so far only other respondent to your question lists from the Google blog post), after a bit of research GTMAppAuth seems to be the most viable option to me, as I am not interested in complete user sign-in and -out. But I may be wrong there.
GTMAppAuth has sample code for iOS, yet just in Objective-C. I have yet to make it through that. In general, your code logic will change like so: Your current solution does authentication purely within your app. It's asynchronous, but doesn't leave your app. The new solution requires you to initiate authentication within your app while preparing and remembering your callback functionality. The authentication initiation then opens a browser outside, which, once done causes a URL callback in your app delegate. In your app delegate, you then check for your prepared callback and, depending on the result status of the outside call, notify the user about success or failure of the outside authentication.
Add this code to your AppDelegate.m (assuming it is in ObjC):
NSString *userAgent = #"Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X) AppleWebKit/603.1.23 (KHTML, like Gecko) Version/10.0 Mobile/14E5239e Safari/602";
// set default user agent
NSDictionary *dictionary = [[NSDictionary alloc]initWithObjectsAndKeys:userAgent,#"UserAgent", nil];
[[NSUserDefaults standardUserDefaults] registerDefaults:(dictionary)];
You can solve this issue by using the 3rd party SDK by CloudRail which works fine for Google Drive and the new authentication restrictions. This tutorial exactly shows you how to use an external browser rather than a web -view.

How can i redirect only ios uiwebview with htaccess?

I can redirect based on user agent. But because of some weird problems on this work i am doing, i need to only redirect in-app uiwebviews to a sub folder or domain. Mobile Safari should be out of this redirect. Need help...
You can change the user agent of the in-app web views by writing to the standard user defaults with the "UserAgent" key. Here is an example,
[[NSUserDefaults standardUserDefaults] registerDefaults:#{
#"UserAgent": #"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17"}];

(iOS) Will mucking about with my User-agent get my app rejected?

In my app, I use the following type of code to muck with the User-agent:
// Fake Firefox's user agent during web service's registration
NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:#"Mozilla/5.0 (compatible; Windows; U; Windows NT 6.2; WOW64; en-US; rv:12.0) Gecko/20120403211507 Firefox/12.0", #"UserAgent", nil];
[[NSUserDefaults standardUserDefaults] registerDefaults:dictionary];
// Return to standard iOS user agent when web service registration is done
NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:#"Mozilla/5.0 (iPhone; CPU iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3", #"UserAgent", nil];
[[NSUserDefaults standardUserDefaults] registerDefaults:dictionary];
Part of my app allows the user to register for a web service using its "sign up for an account" page, and the only way I could find to prevent its website from automatically launching a page which says "DOWNLOAD OUR APP INSTEAD!" is to muck with the user-agent string thusly. I've tried setting the User-agent in a NSMutableURLRequest but I have NOT gotten this to work at all. (Yes I have tried setting both "User-Agent" and "User_Agent" in the NSMutableURLRequest.)
I have heard that this might get your app rejected from Apple. Can anyone confirm or deny, or offer any comment? Thanks!
There are multiple apps on the App Store that fake the user agent as well.
All workarounds for setting the language of NSLocalizedString set a custom value for an Apple key in the NSUserDefaults as well
So I don't think Apple will reject your app.
We use custom user agents in our apps as a way for our servers to know that our app is calling - and to pass extra data, for example, whether the app has a retina screen. As long as you don't rely on this for security it works well. Nothing has ever been rejected as a result.

Have Chrome pretend to be an iPad

I am sure that I have seen someone impersonate iPad Safari in Chrome. Do you know how?
Browsers identify themselves by the 'user-agent' string in HTTP request header
You can change it https://chrome.google.com/webstore/detail/djflhoibgkdhkhhcedjiklpkjnoahfmg?hl=en-US&gl=US
Here's a tutorial that shows you how to accomplish this. You simply change the user agent to be the same as that of ipad safari
Get Ipad interface using Chrome user agent string
I might be wrong but I think this mostly has to do with the user-agent string that the browser sends. When testing access scenarios it is useful to impersonate other browsers such as Safari or Mobile Safari from a Windows PC. This can be done with Chrome using the following syntax when launching the app. This example impersonates the mobile safari browser on an iPhone. Try this -
chrome.exe --user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3"
There are many “user-agent” strings that can be added to this syntax and a google search should discover the correct one required.
This is very useful during testing when one wants to know how the back-end systems behave when requests from different browsers come in.

Resources