We were trying to create a mobile HTML5 web app. We call a service hosted in domain xyz.com using javascript and we run into the same-domain origin policy issue. We have to use CORS to make the cross domain requests. But if I make the same request using a native iOS app, it works fine even without the access-control headers that are needed for CORS.
This may seem like a noob question, but why does same origin policy only apply when making calls using javascript for web apps and not for native apps?
It's completely arbitrary to be honest but there is some thought behind the policy. In Javascript land you are much less in direct control of what's being executed and from where.. take a look at this page alone and you'll see several different server sources.. and so the same origin policy was implemented in order to minimise the risk of running arbitrary, untrusted code from third parties within your browser.
In native land you have more control and must actively choose to instantiate a JS context and run whatever you've received.. so it seems reasonable to suspend the same origin requirement in that case.
Related
I'm planning an app for work and venturing into potential features which I've not used before.
Essentially I need to be able to access files on a network share, read, write and delete files as well as amend the file names. As a pretty closed platform I'm not sure whether iOS is capable of such a thing and if it is, what features should I look for to begin researching?
My Google-Fu hasn't come up with anything thus far so hopefully looking for someone to point me in the right direction.
Thanks.
I know this isn't very secure, but I'd personally create an ASP.NET app on your target Windows Server, or a different Server on the domain. Create web services exposed, and make an iOS app with UIWebView. You can do RPC calls from the web service that do WMI/ADSI/File System manipulation. You can prompt for domain credentials, and do remote calls essentially is the gist.
You could expose the web app so that your app can access it from local network, or URL. If you were to access it from outside I'd suggest using some secure credentials in Windows/IIS.
Some years ago I created a "mobile-friendly" web app that allowed me to manage servers, perform RPC, and do basic Active Directory queries. Also allowed file listing and deletion/moving/copying with some creative scripting. It was essentially a ASP.NET/C# web app that loaded in a iPhone app. UIWebView in iOS was a able to load it, used AJAX and some other client side scripting that looked decent. You'd essentially have to make sure that your web app renders properly in Safari/UIWebView (which is bastardized safari).
Here's a link to a demo of what I created:
https://www.youtube.com/watch?v=czXmubijHwQ&t=12s
I ran it in a browser, but it'd run from my PSP, Android test devices, iPod Touch, Blackberry, etc.
My company's site is mostly server rendered (we make some use of Structured Page Fragments) but we'd like to look into building a Progressive Web App.
Does it make sense to build a Progressive Web App by implementing service worker caching for server rendered pages? Alternatively, should we rather explore moving to client side rendering?
Note that we'd like to do as much rendering as we can on the server as we support many very slow devices.
Yes, service workers are definitely not restricted to client side rendering.
You can cache whatever you want. For example, this WordPress plugin caches WordPress content.
Server-rendered pages imply that there is some degree of dynamic or personalized content on your site—otherwise, you'd just be serving static HTML.
I'd encourage you to initially think about it from the perspective of how you want to deal with your dynamic content, both when you're online and offline. Reading through Jake Archibald's Offline Cookbook will give you a good overview of the different strategies that could be implemented.
Once you're set on a caching strategy for your dynamic content, the next step is to implement it. The "gold standard" approach is to use an App Shell + dynamic content architecture, but it can take some refactoring to get an existing application onto this architecture, especially one where the initial HTML returned by the server contains dynamic/personalized elements.
If refactoring is too daunting a task, or if server-only rendering is a hard-requirement, then you can still make use of service worker caching, but you'll probably end up treating your would-be shell as if it were dynamic content. This means a pure cache-first strategy might not be "safe", but a cache/network race might work, or at least network, falling back to cache.
Using both of those strategies, you'd end up with a web app that would work offline, but you'll likely end up caching duplicated data (i.e. if /page1 and /page2 share some common HTML structure, you'd end up caching that twice). You'd also take a performance and bandwidth-consumption hit since you'd have to go to the network more often than you would with an App Shell, but that could be mitigated somewhat via proper HTTP browser caching headers. (Which you should think about anyway, for browsers that lack service worker support.)
This might be a silly question, but wondering if I was able to build an iOS app completely in a UIWebview. Essentially not have one thing be native to iOS.
You can actually. There are several ways to use HTML5, CSS3, and Javascript to make mobile apps like iOS. You can use frameworks/programs like Cordova/PhoneGap. These frameworks/programs can let you use web languages and then compile it into an executable for the device. Something that can be submitted to the AppStore. Whether or not Apple accepts it thats another story. ;)
The other thing you can do is you want it to completely run off the web is you can essentially build a web app on a server like any other web app. However, you can put in CSS3 media queries and Javascript that can detect the size of the screen. Users can use their built in web browsers to access your site. If the screen isn't the right size, then you can redirect the user like if they try to access it with a laptop. With this method you can use server side scripting languages like PHP to do your computation processing. However, connection is required to the server and if a whole lot of people log in to your server, then the server can get bog down.
If you are interested in using web base languages for mobile applications, I highly suggest looking into PhoneGap/Cordova.
So I am currently evaluating Dart's use as a potential language to re-write a campus organization's website. One critical aspect of this website is it's access control policies. It seems that anything written within the Dart web apps could potentially be compromised, and thus led me to asking the following question.
Is it possible to securely implement access-control to pages in Dart, using either just a web app or a combination of a web app and a dart-implemented server? Could it also be possible to implement that same concept using Apache with a proxy-passthrough to dart?
I don't understand what you actually want to achieve with a proxy-passthrough.
When you create a single page app in Dart all client code is loaded to the client. This is normally no security concern. When a view is shown it usually loads data from a server. Here you enforce security.
You can require the user to authenticate and decide in the server code if or which data you serve for this user or what update command you allow the user to execute. You can just return an error when the user invokes a function that he is not allowed to use.
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.