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.
Related
I've got a server setup with a URL structure like so:
mything.com/services/super.dll?why=doesnt&this=work
This URL returns some plaintext content with Content-Type: text/plain.
On iOS <= 10 and all Android browsers, it works as expected, and I see the plain text response.
On iOS 11, Safari tries to download super.dll. It gives me a screen telling me that super.dll is a Microsoft Windows application with a size of 1KB. I have the option to "Open in 'Files'" and "More...".
I have no idea what's going on under the hood that might cause this. Has anyone else seen this behavior?
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.
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()
}
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.
Does anybody know why this url works fine on a desktop browser (Safari) but mobile safari or UIWebView can't handle it
http://itunes.apple.com/us/app/groupon/id352683833?mt=8
They give
WebKitErrorDomain code 101 and 102
Because the server (at Apple) detects that the user-agent is an iPad and probably sends a redirect to a different URL scheme (the App Store's scheme in this case).
Just tested out that url, on my iPad, with Dolphin browser, using the desktop mode (different user-agent), and it worked perfectly.
You can verify if this is the case (I bet it is anyway) by intercepting your iPad's http traffic.