I'm communicating with an API that requires I use a particular user-agent string. The format for this is basically User-Agent: IOS_USER_AGENT API_CUSTOM_AGENT
Upon investigation I discovered that people would use UIWebView and apply a javascript function to extract the system user agent string. Now that UIWebView is deprecated, its replacement WKWebView offers an asynchronous means of calculating the user agent (not ideal for my purposes).
Is there any way to extract some form of the iOS user agent string without needing to randomly create some off-screen web view. Especially with SFSafariViewController I don't think its entirely impossible that these web views become deprecated in future.
I know that Apps like WhatsApp and Facebook use the system User-Agent see here. The question is, what is the most reliable way of achieving this without involving web view trickery?
Related
I'm referring to the "Internal UUID" value that's visible in about:debugging, which is different from the extension ID that is specified in manifest.json for web extensions.
In my testing, this is a different value for each installation of the addon.
I'd like to set this to a predictable value because it is used as the origin (e.g. moz-extension://guid) for communication APIs like postMessage. It'd be a good indicator for whether a message received by a web app is from an authorized extension vs. some other extension or page.
In Chrome, the origin seems to be stable across different installations of an extension, so I'd like to see if it's possible to achieve the same thing with Firefox.
The internal UUID is deliberately created per installation of an extension, to avoid fingerprinting, you can see a longer discussion at https://bugzil.la/1372288
However, I think you're misunderstanding the purpose of the Origin header, it lets your web app and browser work together to prevent a class of cross-site scripting attacks. But by itself, it doesn't really give your web app a reliable indicator of the origin of the request (that is, any non-browser client can easily construct an HTTP request with an arbitrary value in the Origin header)
I recently got my hands on an relatively old cordova app for iOS (iphones), which was built around one year ago, in order to debug it.
The app queries an API from a server. This server is built using Laravel and makes use of laravel-cors.
For a peculiar reason, the developers of this app have set up CORS server-side to accept requests, only if the Origin header is missing.
I was told that the app was working just fine for the past year.
While debugging it, I noticed that the iOS browser adds origin => 'file://' to its headers, when cordova app uses $.ajax for doing requests
And now for my questions
Are you aware of such a change on newer iOS verions?
I suppose I can't do anything client-side in order to bypass it?
How safe is to add "file://" as an accepted origin, server-side?
Thanks a ton!
The reason the server accepts null-Origin isn't "peculiar" -- that is how CORS is defined to work. It is intended to protect against browser-based XSS attacks -- browsers send the Origin header automatically so the server can accept or reject the request based on which domain(s) they allow javascript calls from. It is intended as a safe standards-based successor to the JSONP hack to allow cross-origin server requests, but in a controlled way. By default, browsers require and allow only same-origin XHRs and other similar requests (full list).
CORs is undefined for non-browser clients, since non-browser clients can set whatever Origin they want to anyway (e.g. curl), so in those cases it makes sense to just leave off the Origin header completely.
To answer part of your question, it is not (very) safe to add file:// as an accepted origin server-side. The reason is that an attacker wishing to bypass CORS protections could trick a user into downloading a web page to their filesystem and then executing it in their browser -- thus bypassing any intended Origin restrictions since file:// is in the allowed list. There may also be other exploits, known and unknown, that could take advantage of servers that accept a file:// origin.
You'll have to evaluate the risks of adding this based on your own project requirements.
I am wondering about what the best way to keep users in sync with each other in a social network is. The concerned stack is an iOS app with a NodeJS backend. Let me give you an example:
Say X and Y are friends on a social network. Y's posts appear in X's feed, and as such, Y is cached somewhere on the X's phone. This morning, Y decided to change profile pictures however. Everything is well, the new picture is uploaded to the server, but how do we go about letting X know about the change of profile picture?
My possible solution: Create a route /<UID>/updates that contains a stack of "cookies" which lets the user know what and who changed since the last time they made a GET request to the route.
This seems elegant enough, but what worries me is what happens on the client side (am I supposed to make a GET request every 2 minutes during my app's uptime?). Are there any other solutions?
One solution is indeed to poll the server, but that's not very elegant. A better way is to make use of websockets:
WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
They are a 2-way connection between client and server, allowing the server to notify the client of any changes. This is the underlying technology used in the Meteor framework for example.
Take a look at this blogpost for an example of how to use websockets between an iOS client and a NodeJS backend. They make use of the open source SocketRocket iOS library.
Hoping someone has some knowledge on this one. I have a system which allows users to post to facebook or to send a link via email using an ESP called dotMailer. When creating the wall post / email campaign however, both Facebook and dotMailer 'test' the URL embedded in the content to see if it's valid.
I am storing a viewed_on date for the URLs, and as such I want to be able to ignore the HTTP requests by Facebook and dotMailer rather than storing the viewed_on date that they trigger by hitting the URL.
In terms of what I've tried / won't work:
IP Filtering - cannot rely on IP being same each time
Time-based delay - depends on how quickly dotMailer/Facebook processes the requests, so cannot rely on this
Thanks!
I'm a dev with dotMailer - for us, you can rely on the request coming from one of two different places: 94.143.104.0/21, 80.249.97.113, or 80.249.97.114. With Facebook, you can simply check the UserAgent. We use an IE useragent, because a surprising amount of sites behave differently when presented with a non-standard useragent and thus make link checking less reliable.
We've got a great forum, so stop on by if you have any more questions! https://support.dotmailer.com/forums
I'm writing an application, which becomes "useful" once user is browsing certain url.
I want to add feature to my application, that it will be automatically launched once user browses this url, I was thinking of writing some sort of watchdog to trigger it.
My question is, whether there is a generic way to get notified when user browses to urls, I want to support at least IE and FireFox, chrome and safari is nice to have.
I read about DDE and WWW_RegisterURLEcho, but from what I understand it's not supported by FireFox, and also little sample I wrote didn't work with IE as well.
Thank you in advance
some more questions **
Do Url Monikers and Asynchronous Pluggable Protocols help me here ? Is it supported by FireFox ?
If you have control over the website, you could have it write a cookie to the computer. Then have your application monitor for that cookie.
You can implement this in many ways and at many different layers.
At the highest level, you could implement a browser plugin. There is no cross-browser solution at this layer that will let you write the code once and work for every browser. On the easy end of the spectrum, Firefox, you could implement it entirely as a Javascript + XUL plugin and use built-in XPCom interfaces (nsIProcess) for launching your helper process. For IE you would need to write a COM, C++ and win32 BHO that handles DWebBrowserEvents2::BeforeNavigate2. This is the hardest thing to do. There are mechanisms for Safari, Chrome and other webbrowsers that you could use to achieve this same behavior, with varying degrees of difficulty.
At the next level you could implement an HTTP proxy, similar to Fiddler2, that redirects all HTTP traffic through your local proxy first. Each browser has a different way of configuring its proxy settings, but they're all basically registry settings or config files.
At the most basic level you could just snif all IP traffic going out of the machine, similar to the way Wireshark does it, and just look for http requests to your URL. This is probably more difficult to code, but would work for all browsers without any special per-browser configuration stuff going on. You may need to write a driver. I dunno, I've never done work at this level in the stack.