Thread

This is a list of features maybe people would like to include (I thought we could include them, but to make them easily deletable, to keep the library light if people don’t need them. Do you understand what I mean?)

✓ 1.- Signin/Signup with Facebook, Twitter and OpenID (Google, Yahoo, AOL, MySpace, Others). Check codes updates
✓ 2.- Traditional Sign Up, Sign In (with remember me) and Sign Out. Sign In with email/username?
✓ 3.- Manage Account/Profile Details (including Profile Picture)
✓ 4.- Manage Linked Accounts
✓ 5.- Forgot/Reset Password for native accounts
✓ 6.- reCAPTCHA support. Support for native CI Captcha?
✓ 7.- SSL support
✓ 8.- Language file for i18n (plus all the necessary i18n tables, country, language, ip to country, etc)
✓ 9.- Semantic XHTML views
10.- OAuth server with ACL
11.- OpenID provider
12.- Activation Emails
13.- Admin UI
14.- Banning
15.- Documentation!!!
16.- Failed Login Attempts
17.- Roles (inheritance) & Role Permissions
18.- Delete Account

What else?

which webpage are you referring to that i compared 4 auth projects? cuz i don’t remember doing so. not sure i understand what you mean by special feature, so not that i can think off.

-

ok a3m = account, a1 (authentication) and a2 (authorization).
what you are currently seeing is only account + a1 = sign in + sign up + forget password + reset password + update of user info / profile + 3rd party sign in account management

oauth is kind of standalone from everything else, so you can ignore it for now. oauth is for ppl who are building APIs that need authentication.

what’s missing is authorization which is where an ACL (access control list) comes into play.
basically it has 3 object: users, permissions and roles. a user can have permissions. a user can have roles. a role can have permissions. the ACL module i did is a admin panel to manage those 3 objects and their relationship.

e.g. a user signs up and has a a3m account. from the ACL panel the “admin” can create a role with certain permissions and assign it to that user. the programmer will then do a simple check to see if the signed in user has the necessary permission to access a certain feature. something like…

if ($this->authorization->has_permission($data['account']->id, 'access_control_management'))
{
  // jump for joy
}

ok let’s get back to the currently available a3m package…

i must mention that a3m has some controversial design decisions in terms of usability.
which not everyone will agree upon. but based on certain principles, i choose to take that path. off my head the two most controversial design decisions is…

1) for traditional authentication, one can only login with username/password
not email. the reason is emails can be repeated. meaning two users can have the same email. which stems from another design decision. should we ask users to go thru that painful ‘verify email’ process? why do we want users to verify emails? yada yada… i think there’s a long ass discussion on this somewhere in this thread. but basically the a3m conclusion is that. one of the main ideas of a3m is to super charge the sign in and sign up process in terms of usability. the question i keep asked myself is “What is the easiest and most pain free way to do this.” no one likes sign in and sign up so we should make it as pain free as possible. even if it means giving up a bit of security.. that’s acceptable (save your flames 😉

2) you don’t need to type ur existing password to change a password 😉
juz be signed in and you can change ur password. we can sit here and argue all day on this and still not come to agreement, but after careful consideration, survey conducted internally, we decided it’s not necessary. I say “we” becuz my colleagues helped me brainstorm many of these decision thru and thru.

users are users at the end of the day, all the want is to get something done. they won’t care even if they write their password down and tell it to their friend, bah bah… all the things which geeks and security dude would jump at. So the disclaimer is a3m isn’t designed for your internet banking website.. it’s designed for your social websites and community portals, etc. basically if someone loses his acc there’s no heart stopping repercussions. admin simply helps him reset his password! Don’t punish 95% of users with bad usability becuz of 5% of users who are going to lose their password. Somewhat that’s the idea.

well seems like a good round of boosting here.. is this going to be SVN’ed in Google Code ? and have you commited the latest acl thing… Im willing to design and develope the Admin Panel (add users, delete, ban etc…)

OK. This is a page that links from A3M wiki (author’s web), and I thought you had written it. Sorry if you didn’t. And thanks for the explanation of ACL, it’s just I didn’t remember what the letters meant.

I’ve just read an interesting doc about user experience on this kind of login; and referring to “username/email” I’d always choose to user email. I’m surprised you said an email can be shared by two people, because I had never thought about it (I would never share my personal email account with somebody else).

I think we should think about the “normal” user, and sharing an account it’s not the usual way, I think. That’s why I find this point really controversial, since I’d like to user emails, which are btw verified by the original IDP (ID provider, in this case the email provider, like Google Gmail, Yahoo…)

The document I linked above is interesting about the way users sign in, avoiding to ask for passwords twice and verify emails, if they’re asked when you sign in/up with Gmail, Yahoo… This way we’d rely on trusted partners (Google, Yahoo) for those processes, making user experience (usability) easier and nicer. This of course applies to people who have a 3rd party account, not for “legitimate” users (users native from our site, registered with us), which I think email verification could be done later (let them sign in before they click the “verify account” email link, for some days).

And about the 2nd point, it’s true we could be arguing the rest of the decade. I think we should distinguish between helping the user to recover his password, and users’ bad practices. I’ve seen friends of mine who never sign out. What happens if someone takes that account, change password, email…? How could we help the legitimate user if everything has been changed by the intruder?

We should minify the pain for the user, but nowadays security cannot be relied on the user like, as you say, they show their passwords to friends and so. So we are the people who have to take care for them. Maybe thinking of another way (I’m not saying password check should be “the only way”, just that we should provide security too!) Maybe session/IP check, or check trust it’s the user only if he’s been signed in for less than 24 hours (he’s just come), but if he tries to change it 6 days after (“Remember me” checked, of course), we should check if it’s really him, and not his sister trying to ***** him!!!

It’s good that we share our ideas!!!  😊

Hi, there yeahs I wrote that article. I hope to help document A3M sufficiently enough and eventually create Video Tutorials on how to use it. I’m also willing to design the user interface of the administration area.

I think logging in with the username is by far the best option.. a username is an online identity, and peoples email change. usernames make the identity on a website for less complex. a username can be used for everything all at once… ie.

- login in
- comment
- post
- avatar
- Profile field. e.g. http://domain.com/USERNAME

i firmly stand by only logging in via username. I dont see why not. Besides, with A3M people authenticate via gmail, facebook etc…. SO What if he/she loses ‘email’ if they use a social networking site to login in.

For me, this is my strongest opinion on the entire features of a auth lib.

final points-

- easier to program the flow of the entire app with usernames.
- one id, is better than an email AND a username
- Clearer programming when linking usernames to other things like Profile, Posts, comments, etc
- Lost password should not be an issue, just have an auto generated password.
- Account verification is redundant, ... If the user hasnt logged in after 4 days of signing up.. clean him/her away.

Im of the philosphy… of SPEED, SIMPLICITY (both for developers, designers and end users.)

Lets not make this a sudoku puzzle. and just give the end users what they want simple.

thanks
ill be blogging about this on sirwan.me

Hi, sirwan.me. Nice article. Let’s make A3M better than the rest 😉
First, I’d like to correct the link I posted before. THIS is the article on User Experience. Very interesting, and I’d like to discuss its view here.

Let me explain my point of view: I’m not against Username as log in, but it cannot be the only one. Give some hours to write a whole explanation. Meanwhile I’ll write brief description.

Username is good for memory and people who don’t have email.

But let’s face the future: we have Facebook, Twitter, Gmail Connect… all of them try to make us write our social profile on them. Then, why make the user write again his username, while we could have not only his username (for posts/comments/profile) but his gender and language to send him emails through only ONE email?

I hope you see the point at least (I know you won’t share it so far, but at least know what I’m trying to say)  😊

We should face situations like “I changed my email on Gmail and now I cannot access your website” or “I lost it and I’d like to log in to your website while I recover it from Gmail recovery system”.
We cannot focus on one static way. That’s the past. I’m angry because every forum I try to add to my website don’t have native ways to user Gmail/Facebook/Twitter accounts… Let’s build for the future, not the past.

Please give me time and I’ll (try) to post a whole bunch of situations (username/email remembered/forgotten/lost/changed)
I’ll “speak” to you later 😊

iv read the document linked above, (not all of it since its very long)..my conclusion is that this is a very very exhausting procedure. especially for this to be on a MySQL database. it’ll probably triple the amount of queries just to find the human readable user name of the author of this ‘post’. But it does seem like it is going to be the future. anyway. what about this.

Buttons
———-

instead of entering emails, user name or password to log-on. How about we just use the Facebook, Gmail buttons. to register and log-on and LINK SOCIAL NETWORKING ACCOUNTS. You can also link multiple emails (for password reseting and blah blah) .. set a user name (which can also be changed in user settings) that’s it?

i would have thought that would be simplest idea. besides, if someone wants to register (WITHOUT A SOCIAL NETWORKING ACCOUNT per say) ... wouldn’t he/she need to provide a Gmail, Yahoo or Msn email anyway?

Here I’m again. I’ve written a draft of situations. Of course there are flaws, but take a look, I’m trying to cover every situation.
*IDP = ID Provider (email account provider like Gmail, Yahoo, AOL…) I define it as “Trust” when we can communicate with it, and “Untrusted” when it a mere email service (small company email account)

NO EMAIL (people without an email account: children, old people or people who don’t want to share it)

1) Registration: Username + Password
2) Login: Username + Password
3) Recovery:
              a) Username: NO WAY!!!
              b) Password: Username + Secret Question

EMAIL

1) Registration:
              Email:
                          - IDP* Trusted: Retrieve Username (ask for one if blank) + Ask for Password (for log in without email)
                          - IDP* Not Trusted: Ask for Username + Ask for Password
              Username: the same as user without email

2) Login:
              Email:
                          - IDP* Trusted: connect to IDP and, if successfull, log in.
                          - IDP* Not Trusted: + Password
              Username: Username + Password

3) Recovery:
              Email:
                          - IDP recovery process.
                          - Login via Username + Password
              Username:
                          - Login via Email
              Password:
                          - Login via Email from Trusted IDP (not requires our stored password)
                          - Login via Email from Untrusted IDP + Secret Question/Send new password by email
                          - Username + Secret Question

Please, any doubt about my scheme, ask it.
Then, discuss.

iv read the document linked above, (not all of it since its very long)..my conclusion is that this is a very very exhausting procedure. especially for this to be on a MySQL database. it’ll probably triple the amount of queries just to find the human readable user name of the author of this ‘post’. But it does seem like it is going to be the future. anyway. what about this.

Buttons
———-

instead of entering emails, user name or password to log-on. How about we just use the Facebook, Gmail buttons. to register and log-on and LINK SOCIAL NETWORKING ACCOUNTS. You can also link multiple emails (for password reseting and blah blah) .. set a user name (which can also be changed in user settings) that’s it?

i would have thought that would be simplest idea. besides, if someone wants to register (WITHOUT A SOCIAL NETWORKING ACCOUNT per say) ... wouldn’t he/she need to provide a Gmail, Yahoo or Msn email anyway?

I read your post after published mine.

1) Queries on MySQL. For example, a post would have the user ID (“85875” for example). But when displaying it, just JOIN the Username (with a good index it’s quick enough). Simple?

2) I had also thought about eliminating username registration and relying only on 3rd Party systems (Gmail, Yahoo, MSN, Facebook…) It’d be a lot easier, and you’d rely their authentication.

I’ve just read an interesting doc about user experience on this kind of login; and referring to “username/email” I’d always choose to user email. I’m surprised you said an email can be shared by two people, because I had never thought about it (I would never share my personal email account with somebody else).

lol u got me wrong. i’m not saying share email with others. i’m saying one email can have two accounts. unlikely and it’s not the intent. one user usually only would ever have one acc. but the problem is if you don’t verify what’s stopping someone from putting someone else email? the point is it’s pointless.. cuz email is only used for communication.

erm guys don’t debate seriously don’t. juz fork a3m and do it the way you like.

just don’t use the name a3m since it already represent this 😉

for a3m. it’s suppose to be the future where openid/oauth is used.
native signin with username and password is only a fallback for a small minority of users.
in the first place people shouldn’t let small sites manage their password… let facebook or google do it man.

so only a small minority of users on a3m will ever see the manage password page
and care about signing in with username + password.
so really this is an unimportant debate.

mass majority of user should use facebook or google.
small minority who use native sign will/should at some point connect their facebook or google.

why even type username+password when you can click one button and be signed in?
tell me what is more simple then clicking one button to sign in?
nothing is more simple! users will use the most simple way cuz their lazy.

i’m against email verification cuz it’s troublesome like hell.
it’s imo an old way of doing things. you verify cuz you want a “back up” channel to verify the account owner. in the new world openid changes all that, there’s no longer a need… that’s why i did away with email verifications for a3m.

mobile is the future. tons of pple surf the web using mobile phones. go check the statistics yourself. you think verification is not a hassle? try doing it with ur mobile phone 😉

ok let me correct myself… i’m not saying never verify users email.
im saying don’t face users to verify the email as part of the sign up process.

currently native a3m sign up is… enter username, password, email = sign in
currently native a3m sign in process is… enter username and password = sign in
currently a3m sign up process is… click google/facebook/etc, enter username = sign in
currently a3m sign in process is… click google/facebook = sign in

a3m is MINIMALISTIC. doing away with EVERYTHING it can do away with.

let users sign in freaking easily and start using your website.
then later on can slowly collect the 100000 info you need and ask them verify as many emails as you like 😉

OK, now I understand what you meant. That problem would be only in case with Untrusted IDP, because for Trusted IDP it would be necessary for the user to authenticate himself there, and if he’s not the owner, no possibility to register in our site. In the other case, an email verification should be advised. That’s a problem of security, but I’m focusing on connectivity.

Don’t get me wrong neither: I see Usernames could be more intuitive, to users and to developers; but let’s be real: email could let us take advantage of Social networks, where people write all their profiles. We can use that to avoid him write a info again, excepting certain cases (email already in database, taken username, untrusted IDP…)

I know it’s a complicated, but I’d like to make something that won’t be out-of-date in a year, where users profiles (as it seems is gonna happen) goes through Social Networks; they’ll have all the profile info. Let’s make the visitor enjoy his visit to our web for the content, not for having to rewrite/revalidate/remember data.

EDIT:
I’ve just read your last post. Of course I’d like to sing up/in with just a click; even just entering your email and the system detecting what kind of email it is automatically, without pressing ANY button. That’s my main purpose of this!!! But we need to think of people who don’t have email. All situations should be taken into account.

if you sign in with google. the site automatically has your email.
if you do a native sign in you have to provide the email.

anyway really guys it isn’t that hard at all to add in email verifications and stuff.
that the whole beauty of a3m.

it’s designed so that it’s a piece of cake to extend and reuse code.

as long as you understand how it’s designed…

so why not we discuss how it’s designed… rather then our dream authentication system.

once we all understand how it’s designed… we can go off and built whatever best fits our need
using a3m as a base to super charge kick start development.

i spent 3 months developing it on an ad-hoc basis so you guys can develop exactly what you need in half the time.

All situations should be taken into account.

exactly. that’s why i didn’t leave out a native sign in option 😉