Is there any way to view the get/post requests being made by an app from a users perspective?
I figure I won't have to worry about cross site request forgery if there isn't any way to view the requests going back and forth from my ios app to the server and it could potentially save me a lot of work. But at the same time I don't want to sacrifice security.
If there is a way to view the requests. How would you do it? Can I hook up a sniffer to my iPhone or something? If this isn't too difficult I would be interested in playing around with a couple of other apps (bwahahahaha)...
I use Charles for this purpose. http://www.charlesproxy.com/
You set it up on your computer and then set your iOS device to use it as a proxy. It will show you all network traffic and is easy to use. You can also pass back different information if you want to simulate a server that isn't running yet.
Related
If you had to open a resource from a database in a web browser on another computer, using an Apple tablet app as a remote control, how would you implement such a feature? This is basically what WhatsApp Web does, so it should be technically possible. But how would you go about it?
I'm assuming that you mean a situation where the app modifies something on the server, and the browser then updates automatically to reflect this. If you mean something like the iOS Remote app, then you may have to use another method (and you may not be able to do it from the browser).
To do this you'll have to have a server that both the iOS app and the browser are connected to. When the app does something, it updates the server, e.g. by submitting an HTTP request to a REST API. The server then updates the database.
Now you have to get the browser to update, and there are two ways of going about this. One is by polling the server periodically, using AJAX to update parts of the page dynamically without refreshing the whole page. This works, but there's a lot of overhead and it can be a drain on a laptop battery.
The better, but slightly more difficult to setup, alternative is to use WebSockets. WebSockets allow for two-way communication between server and client, and the connection stays open until one party closes it (or it times out after a long time). The client can submit information to or pull information from the server as before, but the server can also push information to the client without the client having to request it. This would typically be how games, chat clients, etc. can operate nearly in real time.
Setting this up isn't necessarily that difficult, but it's a very broad, open-ended topic that's beyond the scope of just iOS development. Beyond the iOS app and the web client, you'll also need a backend that's capable of using sockets. Node.js is a popular JavaScript-based backend for this sort of application; there are numerous others out there as well. You'll have to do your own research to determine what's right for you.
There are two applications. How can they share information? Can we use a common database for them? Perhaps we can pass parameters from one application to another?
You cannot directly share any resources; every app is in its own "sandbox" and cannot access the resources of any any other app.
You can send data back and forth between apps a couple of ways, however.
If you want everything to stay on the device then you can implement application:openURL:sourceApplication:annotation: in both apps and provide a custom URL handler for both. The user will experience the device switching between the apps as they launch each other.
If you are willing to use a server and internet connection, then both apps can read and write the same server resource. When each app launches or becomes active, it can check for updated information on the server.
I need to view some local (saved somewhere in the iPad) html / js contents with mobile Safari. By reading some threads it seems that the file:// protocol is disabled. Right?
If so, the solution I see is to install an app which turns the iPad into an http server (no need for support of php or anything else), load my contents there and access somehow them within the same device by http://localhost/... or http://127.0.0.1/... with mobile safari.
Is that actually possible? Can someone please suggest me a good web server app which possibly does not require jailbrake or other hacking?
Thanks!
You probably can't do what you want because in order for your application to be serving up HTTP requests to Mobile Safari, it would have to be running in the background, and there's no permissible background mode that covers this.
If you only need a one-time-only response immediately after running your application, then you could possibly use beginBackgroundTaskWithExpirationHandler:, although this might not be approved by Apple - it's difficult to predict their response to that.
If you are sure that you don't need this to go into the App Store, then you can get your application running in the background permanently by abusing one of the other background modes, such as pretending to be a VOIP app or media player.
Once you're running in the background, you can use CocoaHTTPServer to actually serve the files.
If you describe what you are trying to achieve, somebody might be able to suggest an alternative approach to using local files / Mobile Safari.
I am looking for ways where my RESTful web service can let my iPad app know to update its cached data when the server's data has been updated. The server is running on Tomcat & Apache Jersey.
Is this doable? And not using Apple Push Notification (APN)?
There are essentially two options: heartbeat check from the app to the server (on a timer) or something that keeps the line of communication open, such as web sockets. Here is an open source web socket for iOS, but I have not personally experimented with it:
http://code.google.com/p/unitt/wiki/UnittWebSocketClient
I'm not sure why you want to avoid APN, but this really sounds like what it's made for.
If you want to update only when your app is running, there are other options (straight forward polling comes to mind), but if you want the user to be notified even when the application isn't running, there isn't really any other Apple approved way to do it.
Can reverse the design around and make your device a client and pull data from a REST service at a regular interval?? With all the support one gets from REST, it might be helpful to know you will have complete control of when data is being pulled by the device from server and exactly the data that might goto device.
I'm curious to know your thoughts, Thanks.
I'll be building a web-syncing iOS application soon, and we're going to use RestKit. Take a look, it might be a big help.
I'm trying to make an iOS 5 app that features real-time things coming from the server. It will only use these whilst the app is running.
To make it real-time without polling I have been evaluating two design routes:
Creating a socket from the app to the server, and exchanging information via streams.
Pros: Relatively simple and would not involve a 3rd party.
Cons: Battery life drain.
For an overview of how this might work, check
out this excellent tutorial:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Using standard HTTP to communicate with the server, and with each request from the app let the server know what they are viewing. If something new is available for user, send an Apple Push Notification (with no visible alert) to let app know it can go and download new thing.
Pros: Not opening up a new TCP connection, so battery life not drained unnecessarily.
Cons: Feels like a poor hack.
The official docs on APNs http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
I think a socket would be the way to go, but before I commit to it I wanted a second opinion, as this is the first time I've made anything like this!
Sockets would be my choice. I do not know how time critical your application is, but sockets might perform better as APNs if realtime is a must.
Does it really need to be "full real time"? From my point of view i would prefer http since it is already well integrated into the iOS SDK. Its easy to understand, maintain and implement and plenty of documentation is on the web. So maybe a http poll every minute or so will be enough (depending on the app and the number of users). Please consider firewalls too! Traffic to unknown ports maybe denied due to firewall policies of provider or local wifi. So if you really need realtime connectivity I guess you have to use sockets.