I used Abraham examples to implement OAuth into Elgg v0.9.2 (last
version of an open source social network platform).
It`s working as it should be, but I also made further thinking (if by
any chance OAuth gets down) and the first time users join our website
they must complete a "one time" signup process, allowing us to have
the missing parts from theyr account (email - any email they might
choose) and also let them set theyr username/password .
Now, even if theyr password is the same as for twitter it`s md5
encripted and no-one, neither the admins can use it in a "non-right
way".
The signup process is by-passed (from the 2nd time they join our
website using twitter authentication) by saving the twitter ID into
our database linked to the user account (the very 1st time they join),
so everytime the user joins using OAuth a session will be created for
that unique account (ID), but remember that he can also use username/
password to authenticate into our website.
I`ll advice anyone using OAuth to setup this "one-time" account
creation on theyr website (database) too, just in case something bad
could ever happen to OAuth.
If I`m pleased with OAuth? Hell ya, I do..I love it!
Sincerly, Cristian.
On Jul 29, 6:42 pm, Amitab wrote:
> On Jul 28, 4:16 pm, Isaiah wrote:
>
> > I publish an open source example of using a OAuth in a standalone mac
> > app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had
> > to fight to make it appear even somewhat integrated, and the lack of
> > security around my apps private keys really freaks me out.
> > On the other hand I see a lot of posts like this where I tilt my head
> > and say, "what are you talking about?" Because I just don't get where
> > you're coming from. It's like there's some hidden assumption someone
> > forgot to tell me.
>
> > So, please don't take offense, I'd just like to play devil's advocate
> > and ask you to back up these reasons with some more info. I'll try to
> > be specific about what seems odd, or at least odd to me:
>
> > > I really loved OAuth because:
>
> > > (1) Ease of coding. I could get OAuth working within a couple of days.
>
> > You're saying that OAuth was easier to implement than basic auth? How
> > so? Basic auth just places the authorization info into the request --
> > oauth requires the entire token request, token exchange, token
> > inclusion dance.
> > At best I could see someone arguing that it's roughly the same because
> > you can use a nice library either way, but saying OAuth is actually
> > easier seems a bit far fetched.
>
> I was merely advocating about OAuth here. I didn't play around with
> BasicAuth since OAuth was available when I started developing
> twaller.com. I wanted to respond to comments which said, OAuth is hard
> to code etc., by saying I didn't feel that way, mainly because I used
> the library Twitter4J.
>
> > > Saves me any password maintenance, encryption etc.
>
> > But how do you maintain the user's auth tokens? Since they're
> > basically as powerful as a password (so long as the user has not
> > turned them off) they need to be given the same care, right?
> > In my implementation I save them just like passwords. Are other
> > developers not doing this? If not why not?
>
> I think there is a difference. I find passwords messy because if
> someone wants to misuse them, they can potentially misuse them for
> other websites beyond twitter. Many people including myself have
> similar usernames and exactly the same password in multiple websites.
> So if I accidently leak a password, and someone uses that to login a
> bank website and make a financial transaction, that will not look very
> good.
>
> Oauth token's are limited to Twitter use. At the moment, i am not
> encrypting it in my database.
>
> > > (2) Integration with Twitter Branding. With the OAuth scheme, I
> > > believe my website is more integrated with Twitter. It would also be
> > > nicer if Twitter would maintain their own list of websites they trust
> > > with Oauth, just to give users the added confidence that Twitter
> > > trusts me.
>
> > I'm sure if Twitter decided that tomorrow that OAuth was out, and that
> > PAuth or QAuth were the new black, then those would be "more
> > integrated." My point being that this is not an advantage intrinsic
> > to OAuth, just an advantage of using the currently blessed standard.
> > I'll give you that one, if you also agree if that if tomorrow Twitter
> > decided Basic Auth was the way forward, Basic Auth would then be more
> > integrated than OAuth.
>
> I meant the process of going to Twitter for a login makes me feel that
> my application is integrated with them. As oppossed to merely saying,
> please supply your Twitter name and password to my website.
>
>
>
> > > (3) Saves me worrying about SSL. A lot of people are finicky about
> > > HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth
> > > that way in future, we wi
