| A3M - Account Authentication & Authorization Module |
[eluser]gr0uch0mars[/eluser]
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?
[eluser]Peng Kong[/eluser]
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... Code: if ($this->authorization->has_permission($data['account']->id, 'access_control_management'))ok let's get back to the currently available a3m package...
[eluser]Peng Kong[/eluser]
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.
[eluser]loopy2[/eluser]
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...)
[eluser]gr0uch0mars[/eluser]
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!!! 
[eluser]sirwan.me[/eluser]
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
[eluser]gr0uch0mars[/eluser]
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
[eluser]sirwan.me[/eluser]
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?
[eluser]gr0uch0mars[/eluser]
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 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.
[eluser]gr0uch0mars[/eluser]
[quote author="sirwan.me" date="1285014415"]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?[/quote] 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. |
| Welcome Guest, Not a member yet? Register Sign In |
