What is OpenID "Automatic Login"?
I've never heard this term in a technical sense until today. It has suddenly appeared in Facebook's marketing blog in reference to their new deal with Google.
To be clear, they assert that virtually no other OpenID providers besides Google implement OpenID "Automatic Login", thus no other OpenIDs are currently supported by Facebook.
Does this even exist?
FYI, yes this is a programming question. I would really love to see the API documentation for this feature. Please post a link to it if you are familiar with it. Thanks!!
Facebook announcement:
http://www.insidefacebook.com/2009/05/18/facebook-launches-openid-support-users-can-now-login-with-a-gmail-account/
I'm pretty certain that this is just an application of OpenID's "Immediate mode":
Immediate mode allows you to attempt to verify the user without them leaving your site at all. This is normally possible if, during the first time you attempt to verify a user, they choose to always allow you to verify them and offers a slightly more streamlined login experience.
The reason people are excited about this is that it is a much smoother User Interface experience than using just OpenID.
The new system was first demonstrated by Plaxo developers and now has additional information available, see http://code.google.com/apis/accounts/docs/OpenID.html
A blog post from TechCrunch: http://www.readwriteweb.com/archives/google_openid_updates_ui.php
The issue right now, afaik, is that the methodology is poorly documented, so it is mostly appearing on sites that are paying JanRain corp. for their implementation.
Related
Twitter offers 'web intents' that are an alternative to OAuth access to their API. Basically, this provides a less feature rich experience, but can still be quite handy. User clicks on 3rd parts websites can create popup windows that check whether the user is logged in to twitter and if they are, allows them to us some Twitter features such as tweeting, retweeting, or following users.
My question is, how could I go about implementing an API like this? Are there tutorials or libraries? I'm not sure what technologie(s) power web intents or where I should start searching.
Thanks.
You can read more about web intents at webintents.org and read the W3C's draft spec. As far as I know, web intents are still somewhat of a new beast on the web and they have not been standardized.
Still, you may want to read this blog which contains a few examples of registering web intents and check out Paul Kinlan's git repo https://github.com/PaulKinlan/WebIntents
Hope that helps you get started.
I've been working on a web app in Clojure as a side project, and I'm trying to figure out how to do user authentication and autherization. From the googling I've done, I heard about sandbar, but after reading the two blogposts on sandbar (Part 1, Part 2), I left with more questions than answers. I've looked at the source code for 4clojure, and from what I can tell, they roll their own, the problem is that the code's not commented very well, if at all. I'm thinking I need to roll my own system and use either sandbar or noir.session to pass user information around. Could someone please point me in the right direction? I feel like I'm missing something simple.
Chas Emerick's Friend library is now available. It's still relatively new, but looks promising and quite well documented.
I had a look at the 4clojure login code and I think it is pretty clear how the implementation works. Basically it is the traditional HTTP authentication. Post user/pwd in form to a URL, check username and password and update the session with the user info that can be used for further requests to check whether this session is for a valid logged in user.
This is how most of the web app authentication works. Now this is "what to do" part of the situation, for "how to do" you can implement it your self using "primitive" features provided by the web framework or probably use some middle-ware that does this for you along with providing some hooks to customize the implementation a bit.
For authentication, apart from the obvious "rolling your own", I found https://github.com/mattrepl/clj-oauth to work well if you want to use OAUTH (e.g. via Twitter). Once you've acquired user information, storing it in some sort of session object (via ring-middleware-session or similar abstractions) seems to be the obvious thing to do.
For authorization, the way described in the blog post you linked to - wrapping certain routes with an authorization middleware (or whatever abstraction your preferred web stack offers - e.g. pre-route in Noir) works well.
There's also an alternative to Friend called Buddy.
What is the difference with Friend?
Buddy authorization/authentication facilities are more low level and less opinionated that friend and allow build over them easy other high level abstractions. Technically, friend abstraction can be build on top of buddy
This question (or variations of this question) has been asked before, but as Apple's export compliance rules change relatively frequently, and no one seems to ever get a straight answer, I thought I would ask.
I write an iPhone application that uses version 0.2 of the Dropbox API.
I have emailed Apple concerning use of this specific API, and I will be sure to update this question as I learn more and hear back from Apple. In the meantime, if any developer is using the Dropbox API in their iPhone application, did you mark your application as using encryption?
Edit: Upon closer inspection, it looks like the file data is also transferred using SSL. Since their API is using the NSMutableURLRequest class over HTTPS though, I still can't determine whether or not this API "uses encryption." If in the App Store submission page I mark that it does include encryption, Apple then asks if I'm using greater than a 64-bit symmetric encryption key.
If your app uses SSL (HTTPS), then yes it does include encryption. The export compliance rules changed last year though, so you will need an Encryption Registration Number instead of a CCATS number. See this blog post for details.
As it happens I'm working on this right now on a related project.
The Apple position is clarified in the FAQ in iTunesConnect; (my bold)
If your App contains, uses or
accesses standard cryptography for purposes other than those listed in
questions 2-4, you need to submit for
an ERN authorization. Examples of
standard encryption are: AES, SSL,
https.
This authorization requires that you
submit an annual report to two U.S.
Government agencies with information
about your App every January.
It's a pain in the neck, but that is the law if you want to be fully compliant. I'd love to hear that I'm wrong though!
PS. You could always ask for a direct opinion from the Government department concerned here;
http://www.bis.doc.gov/forms/rpdform.html
You can also call the Bureau of Industry and Security help desk at 202-482-0707 or read the web site at http://www.bis.doc.gov/encryption for more information.
Discussing your question with a live person is probably going to be better than filling out the online form and waiting for a response.
I know that Facebook use their own OpenID-like system called "Facebook connect", which you can use to authenticate users on your site, among other features.
In my case I have multiple Ruby on Rails applications:
users.example.com
profiles.example.com
photos.example.com
...
I would like to use 'users.example.com' as a web service that allows users to authenticate to all my other applications the same way as works "Facebook connect" or OpenID. In few words, 'users.example.com' must works as a "OpenID-like system" for my applications in 'example.com'.
Can anyone give me tips and links to some useful resources?
P.S.: since I am a newbie in this matter, I do not know if I'm saying things that make sense. So someone could help me to understand (if I am wrong) ...
Facebook is using OAuth 2.0 and this is now more popular than openid. You can see how to implement it on railcasts or search for "oauth rails" and you will geht enough info about it.
In my opinion this is the thing you are looking for.
This question is an open question since it's not bound to a programming language:
Is it a bad idea to provide users an auto-login feature? Why?
I've been reading a couple of papers arguing that auto-login feature on web development leads to many user having trouble with "hijacked" accounts. However, I would like to read a real answer/comment from someone with experience on this matter.
Well, I think it totally depends on the audience which is consuming the services you are providing.
If you are in an intranet environment, then it is a good idea to enable auto login features. Provides more luxury to the users. But still you must check in the background the application access level for each particular user.
In an internet environment you have much less control - more likely to say no control - of who is going to use the application. Therefore there you should have an authentication mechanism in place and do not provide any auto-login features except through cookies.
HTH