I was searching for a solution of the following problem, so far without success: I'm planning a RESTful web service, where certain actions (e.g. DELETE) should require a special authentication.
The idea is, that users have a normal username/password login (session based or Basic Auth, doesn't really matter here) using which they can access the service. Some actions require an additional authentication in form of a PIN code or maybe even a one-time password. Including the extra piece of authentication into the login process is not possible (and would miss the point of the whole exercise).
I thought about special headers (something like X-OTP-Authetication) but that would make it impossible to access the service via a standard HTML page (no means to include a custom header into a link).
Another option was HTTP query parameters, but that seems to be discouraged, especially for DELETE.
Any ideas how to tackle this problem?
From REST Web Service Security with jQuery Front-End
If you haven't already, I'd recommend some reading on OAuth 1.0 and 2.0. They are both used by some of the bigger API, such as Facebook, Netflix, Twitter, and more. 2.0 is still in draft, but that hasn't stopped anyone from implementing it and using it as it is more simple for a client to use. It sounds like you want something more complicated and more secure, so you might want to focus on 1.0.
I always found Netflix's Authentication Overview to be a good explanation for clients.
Related
I'd like to login to a RESTful back-end server written in Laravel5, with the single page front-end application leveraging Polymer's custom element.
In this system, the persistence(CRUD) layer lives in the server. So, authentication should be done at the server in responding to client's api request. When a request is valid, the server returns User object in JSON format including user's role for access control in client.
Here, my questions is how I can keep the session, even when a user refreshes the front-end page? Thanks.
This is an issue beyond Polymer, or even just single page apps. The question is how you keep session information in a browser. With SPAs it is a bit easier, since you can keep authentication tokens in memory, but traditional Web apps have had this issue since the beginning.
You have two things you need to do:
Tokens: You need a user token that indicates that this user is authenticated. You want it to be something that cannot be guessed, else someone can spoof it. So the token better not be "jimsmith" but something more reliable. You have two choices. Either you can have a randomly generated token which the server stores, so that when presented on future requests, it can validate the token. This is how just most session managers work in app servers like nodejs sessions or Jetty session or etc. The alternative is to do something cryptographic so that the server only needs to validate mathematically, not check in a store to see if the token is valid. I did that for node in http://github.com/deitch/cansecurity but there are various options for it.
Storage: You need some way to store the tokens client-side that does not depend on JS memory, since you expect to reload the page.
There are several ways to do client-side storage. The most common by far is cookies. Since the browser stores them without your trying too hard, and presents them whenever you access the domain that the cookie is registered for, it is pretty easy to do. Many client-side and server-side auth libraries are built around them.
An alternative is html5 local storage. Depending on your target browsers and support, you can consider using it.
There also are ways you can play with URL parameters, but then you run the risk of losing it when someone switches pages. It can work, but I tend to avoid that.
I have not seen any components that handle cookies directly, but it shouldn't be too hard to build one.
Here is the gist for cookie management code I use for a recent app. Feel free to wrap it to build a Web component for cookie management.. as long as you share alike!
https://gist.github.com/deitch/dea1a3a752d54dc0d00a
UPDATE:
component.kitchen has a storage component here http://component.kitchen/components/TylerGarlick/core-resource-storage
Simplest way if you use PHP is to keep the user in a PHP session (like a normal non SPA application).
PHP will store the user info on the server, and generate automatically a cookie that the browser will send with any request. With a single server with no load balancing, the session data is local and very fast.
Does anyone know why Box.com make it so hard to generate an authorization code programmatically? I wrote some code to do this through screen-scraping, and then recently this broke because (as far as I can tell) one HTTP request parameter changed from [root_readwrite] to root_readwrite. I was able to fix it reasonably quickly (thank you Fiddler), but why make developers go to this trouble?
Judging by the number of questions on this topic, many developers need to do this, presumably for good reason, and I don't think it can be prevented, so why not just embrace it?
Thanks for listening, Martin
The issue with doing OAuth programmatically is that it would effectively defeat the point of OAuth. Users are supposed to be presented with the Box login page so that they never have to give their username and password directly to your app. This allows users to see what permissions your app has over their account (the scope) and also allows them to revoke your app at any time.
Doing login programmatically means that at some point your app knows the user's password. This requires that the user trusts you to not do anything malicious, which usually isn't feasible unless you're a well-trusted name. The user also has to trust that you handle their credentials correctly and won't use them in an insecure way.
Box wants to encourage developers to do authentication the correct and secure way, and therefore isn't likely to support doing OAuth programmatically. You should really try to perform login the supported way by going through the Box login page.
I'm attempting to make a mail client that is HTML5/JS only where users would have to define their mail server and credentials.
I've surfed google leading to dead ends and figured that this is the next best place (or superuser.com).
I was thinking of using HTML5 WebSocket if I could to make the connection to the server but I don't know enough of smtp, imap, or pop3's architecture to understand how javascript could pass the args and perform what I want it to do.
PHP cannot be involved in this project otherwise I wouldn't be asking the question.
Any help in locating this would be fantastic.
Nothing is impossible. Except this.
In standard HTML or JavaScript, you can't make raw-socket connections, which is what you'd need to speak any of the protocols you've listed. The WebSocket API doesn't help you, because the server must also speak WebSockets, and mail servers don't. This is actually all a good thing, though. Imagine if you visited a random website and it telnetted to your home router, setting it on fire and burning down your house. That's what websites would be able to do if they could initiate plain TCP socket connections.
You have a few options I can think of, neither of which involves building a webpage. (And to be clear, you didn't say your project had to be a webpage; you merely said HTML/JS, so these are indeed legitimate options.)
First is something like node-webkit. As the readme says, "You can write native apps in HTML and Javascript with node-webkit." You'll still have to distribute it as a native app, because that's what it is.
Second is a Chrome app, specifically using the chrome.socket API. But have fun writing a TLS layer over those sockets, which you'll find is a requirement for almost any mail server these days. If you succeed in doing that, you'll be able to distribute your mail client in the Chrome Web Store, where I assure you an email client will be quite popular.
Third, write a webserver that operates locally, so your users will visit something like http://localhost:9999/mail in their browser. This will be a real pain to distribute, but you can use almost any technology you want.
I'm sure there's a fourth valid option, and someone else can chime in on that one.
Best of luck.
I'm looking for an easy way to implement the XMPP server running with the following protocol:
https://developers.google.com/cloud-print/docs/rawxmpp
The only difference is that I must use X-GOOGLE-TOKEN authentication mechanism: https://stackoverflow.com/a/6211324/227244
The procedure is simple: I get the token from the data sent by a client, request user data based on this token and set the JID accordingly, appending some random chars to the resulting JID.
After that other clients with possibly different tokens, but same user account, connect to the XMPP resource and for clients who are subscribed the broadcast of push notifications is enabled.
What amount of the server code can be borrowed from the currently available implementations? I would avoid writing all of the server code myself, though the logic is pretty simple. I know there're ejabberd and prosody xmpp servers which implement lots of XEP. Which one is easier to add the custom handling mechanism to? Can you suggest other stable alternatives for the core xmpp server?
The way google has designed X-OAUTH2 is dead simple and straightforward to implement. Infact, there is no difference between how PLAIN and X-OAUTH2 mechanisms work. You can simply pick a standard PLAIN implementation and make it work for google X-OAUTH2 authentication mechanism with no extra effort.
I am author of Jaxl PHP library and I recently announced support for X-OAUTH2 inside the library. Here you can see exact lines of code I had to write to support this. The only relevant piece of code is:
switch($mechanism) {
case 'PLAIN':
case 'X-OAUTH2':
$stanza->t(base64_encode("\x00".$user."\x00".$pass));
break;
For X-OAUTH2 implementation $pass is nothing but your oauth token. In short, password field from PLAIN auth mechanism becomes oauth token for X-OAUTH2 mechanism. Rest all remains the same.
I want to implement a discrete remote authentication server that handles login for many sites. Somewhat similar to OpenID.
Basically, I have site-1 and site-2 and they're both reliant on the same user database, which is on a separate auth-site. So, auth-site handles user authentication for them, and during this process, makes information on the authenticating user available to the requesting system.
Each site can be on a completely separate domain name, on completely separate machines.
This is all via HTTP(S), there can be no direct database access.
There's one last quirk: once an user has logged in to site-1, when accessing any other site reliant on auth-site, the site must treat the user as already authenticated.
This whole business must be entirely fuss-free to the end-user. It should work like a simple everyday login form.
As a concrete example, say we're talking about stackoverflow.com and serverfault.com, and they both authenticate via authentic-overflow-server-stack.com. Again, once logged in to either site, I can go to the other and do my business without logging in again.
What I'd like to know are the general interaction mechanism between the sites behind this scenario.
In my particular setup, I'm using Rails, but I'm not looking for code[1], just general best practice and guidance, so feel free to answer in pseudo-code or any generally readable language. OTOH, bear in mind that I'll have decent MVC, REST, and meta-programming in my toolkit.
[1]: unless you happen to know an existing tiny neat free MIT/BSD-licensed app/plugin/generator that handles this.
It sounds like (especially with the emphasis on fuss-free), you want something like what the Wikimedia Foundation is doing. Basically, you log on to en.wikipedia.org, then that server communicates with other servers (e.g. en.wikinews.org) and gets authentication tokens. Finally, those tokens are embedded into images, e.g. http://en.wikinews.org/wiki/Special:AutoLogin?token=xxxxxxxxxxxxxxx , and when your browser visits that url (img src) it gets a authentication cookie for Wikinews. Of course, the source code is available for your reivew at http://www.mediawiki.org/wiki/Extension:CentralAuth .
OpenID is also a good choice, but it does require that the user "consciously" visit two domains. An example of one entity with two domains doing this is Canonical. E.g., if you go to https://help.ubuntu.com/community/UserPreferences they will redirect you to Launchpad (https://login.launchpad.net/+openid) for authentication.
Note that Wikipedia is doing this over http, but you can do it all https to ensure the img src tokens aren't intercepted.
Looks like CAS is good enough for me, and has ruby implementations, along with dozens of other lesser languages, e.g. one that rhymes with femoral bone rage.
http://code.google.com/p/rubycas-server/
http://code.google.com/p/rubycas-client/
It sounds like you want to actually use the OpenID protocol itself. There's no reason you can't restrict the authentication provider to only your own server, and do some shortcuts that make the authentication process transparent. Also, the OpenID protocol supports what you describe about logging into one implies logging in to all services.