I am building an iPhone app where I would like authenticate with a rails server that uses Authlogic for authentication.
I am okay sending the username/password once but would like to use the persistence_token for auth following that.
I am unable to authenticate with the rails server. What special magic do I need to do to get persistence_token to work? Do I pass it in the header or set it in the cookies? Also do I need to wrap it in user_session?
I am using ASIHTTPRequest to make JSON calls.
Many thanks for the help! I am hoping anyone else who has a similar question in the future will end up saving hours once this question is correctly answered. Also, I realize my understanding of persistence_token might not be correct, in that case, please correct me.
Looks like persistence_token is set in the cookies as user_session=. One could set the cookie for every request, but I am just logging in with ASIHTTP once the client is started. ASIHTTP/NSURL continues to save the cookies for all the recurring calls.
Related
We have a REST style API and try to follow the REST principles as close as possible, so of course that includes statelessness as well.
While the most part of our backend is indeed stateless, there is one thing that seems impossible to achieve, and that is dealing with authentication of non API related static resources. I understand that there are means to achieve stateless auth using some token based approaches (e.g. JWT). But that requires setting some headers or transferring credential information in the requests' message body.
This would be no problem when only API requests have to be secured, as we easily can modify XHR or fetch requests accordingly.
But the problem is that we also need to secure static resources like images and audio/video files. For images I could load them via XHR/fetch, though this is already quite cumbersome compared to using a plain image tag.
But as soon as it comes to html5 video/audio, I haven't found a way to achieve this, is it possible at all?
Currently we just use a secured httpOnly cookie, so in that case it is no problem with either images or audio. May using a cookie (having a JWT like payload) generated by the client could be a solution? Of course this would open another potential security issue since now - in case of a XSS breach - the cookie and its information could be stolen which is impossible with a httponly cookie.
Any ideas to achieve a pure stateless authentication that also works for images and html5 audio or video (and that is not less secure as well)?
PS: HTTP Basic Auth is not an option for various reasons.
No ideas? Hmmm. OK so maybe I can answer my own question ...
A potential solution would be to use something like a JWT, but still use a
cookie as the transport mechanism. So the token is generated on the
server, and set via cookie, just like it has been before with the traditional session cookie. Seems like I could have the "best of both
worlds" with this approach:
The client still has no means to access the contents of the cookie,
and therefore does not need to know anything about authorisation. The only thing the client has
to know is the concept of authentication, i.e. asking the user for the
credentials and sending them to the server as soon as a 401 is
returned.
The server is now freed of doing any session management, all it has to do
is validating the token.
And, most importantly: this will work not only for requests where I can manipulate the header and/or message body (like with XHR/fetch) but for any type of static resource as well, including images and html5 audio & video
Does this sound like a good solution? Vote up this answer if you think it is! Thank you.
I like Wickets components and separation of HTML and code, but the stateful pages not so much. I am thinking of creating a Wicket app without server session state. I am not sure how to handle authenticated users, though. In other frameworks authentication can be handled by a signed cookie, which are validated on each request. Can this be achieved in Wicket? Or should I approach this differently?
I see no reason why this should not work!
You just need custom IAuthenticationStrategy. You may use CookieUtils and ICrypt for the implementation.
I have a Facebook canvas app. I am using the JS SDK to authenticate the user on the browser-side and request various information via FB.api (e.g. name, friends, etc.).
I also want to persist some additional user information (not held on Facebook) to the database on my server by making an ajax call:
{ userFavouriteColour: "Red" }
To save this on the server and associate with the correct user, I need to know the Facebook uid and this presents a problem. How do I pass the uid from the client to the server.
Option 1: Add uid to the ajax request:
{ uid: "1234567890",
userFavouriteColour: "Red" }
This is obviously no good. It would be trivial for anyone to make an ajax request to my web service using someone else's Facebook Id and change their favourite colour.
Option 2: On the server, extract the uid from a cookie:
Is this even possible? I have read that Facebook sets a cookie containing the uid and access token but do I have access to this cookie on my domain? More importantly, can I securely extract the uid form the cookie or is this open to spoofing just like option 1.
Option 3: User server-side authentication on the server:
I could use the server-side authentication to validate the user identity on my server. But will this work if I am already using client-side authentication on the browser? Will I end up with two different access tokens? I would like to make FB.api requests from the browser so I need the access token on the client (not just on the server).
This must be a very common scenario so I think I'm missing something fundamental. I have read a lot of the Facebook documentation (various authentication flows, access tokens, signed_request, etc.) and many posts on SO, but I still don't understand how client-side authentication and server-side authentication play nicely together.
In short, I want to know the user's identity on the server but still make requests to the Facebook api from the client browser?
(I am using ASP.NET and the Facebook C# SDK on the server)
EDIT: Added bounty. I was hoping to get a more deifnitive, official recommendation on how to handle this situation, or even an example. As said, I have already read a lot of the official FB docs on authentication flows but I still can't find anything definitive on how client-side and server-side authentication work together.
Option 1:
The easiest way I can think of is to include the accessToken in JS and pass it with the ajax call.
Option 2:
Using the same as option 1, but instead of sending just the accessToken, send the signedRequest.
On the server side you can decode it using (TryParseSignedRequest method) which will give you the UserID :-)
Note: signedRequest is encrypted with the application Secret. you are the only one who should know it, so you are safe on that end.
Disclaimer:
I have no coding experience in C#, but a little search in google gave me this:
Facebook C# SDK for ASP.NET
Making AJAX Requests with the Facebook C# SDK
It's very simple actually.
When the user loads you app use the server side authentication, get the access token and load the user data by issuing an api request from the server.
On the server side you'll have everything you need and it's sandboxed.
When the page renders for the user, using the js sdk get the user authentication data, you should be able to use FB.getLoginStatus since the user already went through the server side authentication.
Now on the client side you also have an access token which you can use to get the user data from the graph api.
The two tokens will be different, and will also have different expiration, but that should not be a problem, both token should work properly as you'd expect them to.
Since both sides have their own token and a way to make requests to the api, there's no need to send any fb data between them.
So the 3rd option you mentioned, to me, sounds the best, and it's really simple to implement that too.
Edit
All facebook SDKs are just wrappers for http request since the entire fb api is made on http requests.
The SDKs just give you easy and shorter access to the data with out the need to build the url yourself (with all the different possible parameters), make the request and parse the response.
To be completely honest, I think that stop providing a way for the C# SDK to support server side authentication is a very bad decision.
What's the point in providing a SDK which does not implement the entire api?
The best answer to your question, from my experience, is to use both server and client side authentication, and since the C# SDK does not support it, my advice to you is to create your own SDK.
It's not complicated at all, I already implemented it for python and java (twice), and since you'll be developing it for your own needs it can be tailored for your exact needs, unlike a public SDK which should support all possible options.
2nd Edit
There's no need to create a completely new SDK, you can just "extend" the ones you're using and add the missing parts that you need, like sever side authentication support.
I don't know if it's language specific but using both server-side and client-side authentication does no harm.
You can work on option 2 but yes, that will be also vulnerable to spoofing.
Doing option 3, you will be having a single access token for that user session, so that would be the best choice according to me since you always have chance of spoofing when passing user information from client side.
I had exactly the same question recently. It's option 2. Check this post from the Facebook blog.
To be honest I am not enough of a hacker to know if you could spoof the UID in the cookie, but this seems to be the 'official' way to do it.
EDIT: to the other question under option 2, yes, I believe you have to access this cookie on your domain.
I am having a strange problem while making an application in iPhone. The problem is in making a POST request to the server API in ColdFusion. We have two servers: one is for Testing and other for Production. The app works perfectly on the Testing server, but when we do a POST request in Production server the API couldn't read the request variable and gives error as Element xxxxx is undefined in ATTRIBUTES, but actually it is there. One reason could be different User-Agents, but after trying many combinations it does not work.
Any help would be very appreciated.
I don't understand why you're talking about different user-agent? It's iPhone to test server or iPhone to production server, no? Is the configuration exactly the same including the Application.cfc (or Application.cfm)?
Web app or native app calling cfc's?
I don't think user-agents make any difference. Try to submit request directly through browser to make sure it is really working. Best way to do that NSLog url request and paste it in browser.
I figured out the problem. It was the "LINK" I was using. The API worked with adding "www" to the link, where as I was using the link without "www". Hope it helps someone.
Thanks.
i am making an app in which there is a need of money transaction...
for this i have to send SOAP xml to server but in secure way....
i have been told that i have to create SSL connection first and then send that soap message.....
I know about SOAP very well but no idea about SSL connection...
please provide some help...
Check out NSURLConnection docs on the apple site: NSURLConnection
EDIT: added more info.
You need to set up authentication. A quick search of SO produced these results:
NSURLConnection SSL HTTP Basic Auth and
HTTPS with NSURLConnection - NSURLErrorServerCertificateUntrusted
You need to set up your server to handle authentication, then issue a challenge to the device. As you can see in the above posts, there is a function: didReceiveAuthenticationChallenge:
You need to use this to handle authentication challenges. You can get a good idea of how to go about it using the above posts.
Your server needs to be set up to handle authentication, as well. I don't know what language you use with your server, but as I use PHP, here is the PHP manual link on authentication:
PHP authentication
It is a tricky thing to do at first, but once you get into it isn't bad (and creating more https connections comes easily). However, writing out everything you would need to do here is a bit much. If you scope out those posts, you can get a general idea about how to go about it. It'll take some working to get it done.
Most often this simply means that you have to send data to an HTTPS endpoint. What this also means is that there is a secure connection (done for you automatically) between the client and the server so that the payload (body) of the message is encrypted rather than transmitted in clear text (which is the case with HTTP).
Basically, most times, it is enough just to make sure you're using HTTPS :)
Have a look at http://en.wikipedia.org/wiki/Secure_Sockets_Layer