I've begun working on the proof-of-concept for an iOS application that we'll be developing that leverages REST-based web services (implemented in Java using restEASY). I will be using RestKit as my client-side services library, and have been reading up on the documentation and some examples.
The vast majority of the services will require that a user be authenticated with a username and password. We have authentication services in place that accept a JSON object containing the credentials, so that part is easy. My question is, how do we handle the iOS piece when a service says that authentication is required?
Imagine this scenario...
A user starts up our app and it recognizes that the user needs to authenticate. A modal view controller pops up, prompts the user for authentication, and submits the request. The user is then able to make a bunch of REST calls with no problem. Eventually, they turn off their phone (app is still active) and come back to it an hour or so later. They click a button to fire off another REST call, but by this time the server-side session has expired.
Ideally, we'd like to be able to recognize that the server has indicated authentication is required, and pop up the modal view controller again. But, does RestKit have support for this? Is there any way for us to register a "global response handler" that is able to recognize that the server has responded this way?
We can return a status code in JSON or use an HTTP status code. We have flexibility on our services. The real question is how to handle this in the ideal way on the client. And, once we've reauthenticated the user, is there any way to replay the request they originally tried to submit? Or, would they have to kick off the action again?
Sorry if this doesn't make sense or if it's a very simple problem to solve. As I'm just getting started with RestKit, I wanted to make sure I was doing this the right way to avoid future problems. Any advice, code samples, tutorials, etc. that you can provide would be GREATLY appreciated.
I would suggest that you make a request to the server in your AppDelegate
- (void)applicationDidBecomeActive:(UIApplication *)application or
- (void)applicationWillEnterForeground:(UIApplication *)application method that sends the old authentication token. The server can then provide a response if the token is valid or invalid.
If your AppDelegate adopts the RKObjectLoaderDelegate protocol then it can handle the response. That way, whenever the application becomes active, the user is prompted to re-authenticate if necessary.
Related
My problem: I'm adding a store section to a rails 5 api only app and to keep the complexity down I'm planning to add it as a separate macroserivce and share the user between the two apps, to auth the users in the main app I'm using a JWT token and I would like to use the same token in both apps.
My not working solution: Use rabbitMQ to send the token from the store to the main app and get back all the user information I need from it. searching around I found this article and tutorial:
https://engineering.adwerx.com/building-a-macroservice-on-rails-with-rabbitmq-and-sneakers-8a394e014a94
https://www.rabbitmq.com/tutorials/tutorial-six-ruby.html
and from those I come up with this solution (I know is absolutely not production ready but I'm trying to get a working MVP before that):
https://gist.github.com/jabawack81/5cfc0983ebd3166fadcd683f335456f0
The problem is: I'm getting the token from the header in the store application controller and I'm able to push it in the queue (inspecting the queue with rabbitMQ GUI) the main app is receiving it, process it but is not replying back.
I recently started getting into Typo3 but now I have to implement something for work and I have no clue where to start.
The requirements:
I have to add a separate page that can only be accessed by frontend
users. (so far no problem)
These frontend users should be able to login with the same password
as they got for their iOS app. (uh-oh)
The separate page should display data from the app. (less of an uh-oh
but connected to the previous point)
After talking to the developer of the app, he made a specific POST request that can be used for the webpage. I am also getting a json-file with the required data that I need to display upon successful login.
My question lies with the login. How do I go about implementing this? I use the extension felogin to provide the login form on the page.
The POST request is looking sort of like this:
https://domain.at/api/queryMediaItems. It needs user and password, declared as user and pwd. In the body there should be a json object with the language, e.g.:
{"language":"de-at"}
You need to implement a SSO (SingleSignOn) as your users need to identify against the iOS-app.
This might give you a concept.
You also can look inside the code of some extension
Has anyone had success using Stripe connect with an iOS app. I have a few questions:
I'm following the guidelines here: https://stripe.com/docs/connect/getting-started
Registering an Application: easy, no problem here
Then a little further down:
Send your users to Stripe: again, easy no problem here, I just have a button that opens up the link in a UIWebView. I assume having the client_id in the URL is fine? A lot of my uncertainty is what IDs/keys I should hard-code into the app
Then a little further down:
After the user connects or creates a Stripe account, we'll redirect them back to the redirect_uri you set in yourapplication settings with a code parameter or an error.
What I'm doing here is using the UIWebview's webView:shouldStartLoadWithReqest:navigationType delegate method to check for the string "code=" in the URL. If it finds that, then I'm able to grab the "code" parameter. So in reality, the redirect_uri is completely unnecessary for me. Is this the right way to handle this? Should I be doing this within my app or on my server?
After receiving the code, we are supposed to make a POST call to receive an access_token. Again, should this be done within the app or on the Server? It requires the use of a secret_key, so I'm guessing server? And how do I send credit card information along with this token if the token needs to be sent to the server? I know how to obtain the card number, exp date, and CVV. But in terms of passing it to the server (with or without the token) is something I'm not sure of.
Then when it comes to actually writing PHP, Ruby, or Python code on the server, I'm at a total loss.
Any help would be greatly appreciated.
You should setup a small web app to create stripe charges and storing you customers Authorization Code. Configure two routes in your web app for redirect_uri and webhook_uri and add the url in your Stripe Apps settings. The charges should be created from a server side app because it requires the secret_key / authorization_code which should not be stored in an iPad app. Otherwise they may lead to a security leak. I'm trying to describe the concept below:
Provide the stripe connect button in your app and set the link to open in Safari (not in an web view). You should add a state parameter to the url with an id which is unique to your users.
On tapping the button your user will be redirected to Stripe where s/he will be asked to authorize your application. Upon authorization stripe will hit your redirect_uri with a authorization_code and the state you previously provided. Do a post call according to Stripe Documentation with the authorization_code to get an access_token. Store the access_token mapped with the state in a database.
Define a custom url scheme in your app. Invoke the custom url from your web app. The user supposed to open the url in mobile safari. So invoking the custom url will reopen your application. You can pass an additional parameter to indicate failure / success. In your app update the view based on this parameter.
Now you are all set to create a charge on your server on behalf of the iPad user. Use stripe iOS sdk to generate a card_token from the card information. It'll require your stripe publishable_key. Then define an api in your web app which takes 3 parameters: card_token, user_id and amount. Call this api from your iPad app whenever you want to create a charge. You can also encrypt this information with a key if you're worried about security using any standard encryption method. You can easily decrypt the info in your web app as you know the key.
When this api is called from the iPad app you'll receive the user_id (which you saved as state previously), card_token and amount. Retrieve the access_token mapped to the user_id (or state). You can then made a charge on behalf of the user using the access_token, card_token and amount.
You can use ruby / php / python / node in the server as Stripe provides sdk for them. I assume other languages can be used as well as there is a REST interface.
Please note that this is just a concept. It should work like it but I haven't implemented it yet. I'll update this answer with sample code when I'm done.
You can use UIWebView. You will still need to use redirect urls and monitor the redirect using the delegate "webView:shouldStartLoadWithRequest:navigationType:"
I need an idiots guide explanation to understand generally how do you authenticate users in your ios app when you have a web based backend? I use tornado and django and understand how to use get/post/delete/update using restkit but theoretically i don't understand authentication requests.
P.S. I have found a good tutorial using restkit for authentication which helped here:
http://benoitc.github.com/restkit/authentication.html
That can be done in multiple ways ill explain the easiest, first lets setup our enviroment, we do have:
www.yourSite.com/login.php: this will take user="name" and passowrd="password", and it will echo back a session ID.
www.yourSite.com/isloggedin.php: to check if user is logged in
www.yoursite.com/logout.php: to logout from your session
First you would call login.php sending the user name and the password (login.php?user=someuser&passowd=pass) this call will echo back a session ID (that will be kept alive for you at the server side)
Then later on you could call isloggedin.php?session=here_set_the_session_returned_earlier, if you didnt log out this will return yes for example
Later if you want to logout you could call www.yoursite.com/logout.php?session=same_session, that will destroy the session saved in the login function
There are alot of other ways to implement this, but in my opinion this is the easiest way
You can use Cookie.
The web server side can respond some cookies when receiving the request that contains username and password information, then the next time app will send request with the cookies the web server has responded.
You can use ASIHTTPRequest, it can handle cookie automatically.
Hope this can help you. :)
My goal is to build a standalone RESTful Rails 3 service that communicates with a Rails 3 web application via ActiveResource JSON and an iPhone application via iOS 5 native JSON. I have each running so that a single table of data is being exposed in the service app and that can be called and rendered via both a Rails app and the iPhone app.
My question is around authentication and something that can be reusable for both the web application and the iPhone app or in the future an Android app.
From the research I have done on this site, it seems HTTP Basic would work for both, however I would be unable to properly logout a user on the web side like sessions or cookies could and I have the browser login form to deal with. If I use sessions, how would that translate to setting up authentication on the iOS side of things?
This project is a code learning exercise, so I am hoping for implementation or architectural guidance rather than simply implementing Devise or Authlogic, etc.
It sounds like you're conflating at least two problems.
The first issue is authentication: you need to determine if the user is who they say they are. For authentication, you can do basic auth. You could also use client certs, though that's probably not what you're looking for.
The second thing is session management: First, you can do basic auth on each page request and store the session state in the database, but you're right about not being able to log the user out, as the browser will cache the credentials.
You may want to consider a login page that requires basic auth and shoots back a cookie to do session management. All other pages don't require basic auth, but give a 401 unauthorized if the cookie isn're present. Or you could redirect. The iOS client code will have to know to call the login page first to get the cookie and then use it after that. Logging out is deleting the cookie.. hrmm, but the browser will still cache the basic auth credentials.
I'm thinking the only way you're going to get what you want is to have a form-based auth for your web users (to allow them to log out and log in as someone else), and a basic-auth based system for iOS users. As a result of both authentication mechanisms, return a cookie that has to be used for all other pages.