Hi Friends,

Get patch from - http://xoops.biz/dist/my_autologin_for_xoops-2.0.9.x.zip

--------------------------------------------------

This is my first XOOPS hack released to public

My hack is highly influenced by GIJOE auto-login hack. This does exactly same thing but my approach is bit refined (I think so, feel free to disagree).

Followings are major changes.

1. In place of making a localized code change, I also changed "kernel/member.php" and added two new methods loginUserAuto (auto-login someone using saved cookies) and loginUserEmail (login someone using email as username).

2. I am using value stored in actkey column for auto-login feature. I too am totally against storing the MD5 of real password in user cookies (like the author of original auto-login and several other people). So here is perhaps the safer work-around. MD5 of actkey is sent to user's browser as cookies and the same is matched for auto-login. I found this column useless after user activation - so why don't we overload it.

Minor differences:

1. I had to change "kernel/user.php" also as it was not persisting actkey column for any existing user.

2. _MB_SYSTEM_REMEMBERME is not used. Rather global variable _REMEMBERME is used to render 'system_userform.html' and 'system_block_login.html' both. I didn't see any reason of duplicating variable for block and main page.

3. Using cookie name 'autologin_key' in place of 'autologin_pass'

4. Using xoops's standard function checkEmail() to test if email was passed as userId.

Looking forward to see feedback from you people

------------------------------------------------------

Q. How to install hack?

A. You should be knowing what you are doing This patch is ok for version 2.0.9.x only and you just need to overwrite files with the supplied ones. (For older versions, serach for the word "sraj" in hacked files and merge the chages manually).

After overwrite, don't forget to update system module

Done, Enjoy...

------------------------------------------------------

GIJOE: Sorry I copied your code-fragments shamelessly. Feel free to merge my suggested changes in your hack. I guess, there are still scopes of making it better.

(If we allow auto-login from just one PC then, every auto-login can reset actkey to a new value and update autologin cookies - perhaps much safer option.)

Cheers,
Sudhaker Raj
sudhaker _at_ yahoo _dot_ com

Fixed and tested

http://xoops.biz/dist/my_autologin_for_xoops-2.0.9.x.tar.gz

With recent pacth - actkey is getting new random value every time user changes the password - so saved cookies will become invalid. SAFER NOW

Enjoy

hi sudhaker

I've just found it.
It sounds good and I'll check your hack.

I'm also thinking how to make auto-login much secure.

1 thing i thought about makin the autologin a little more secure.. and koudanshi implemented it into his x-ipbm module after a request i made which i think is a must really..

an option to select what groups can use autologin.. especially as i didn't want any admins on my site using autologin as a security precaution.. but maybe a further implementation could be for XOOPS to issue a delete cookie command aswell when an admin logs out..

More secure?

By using md5 of actkey as autologin_key we are successfully protecting our confidential information (no password related information sent). If site master wants to invalidate any (or all) saved autologin cookies, he can simply null the column in his server db. Also when user is changing the password, actkey is changed to next random value automatically, effectively invalidating all of his saved autologin cookies. This looks pretty satisfactorily secure and safe to me.

The cookie autologin_uname is sent in plain text, but this is also not a big problem. In fact, uname is known to public already via posts in news and forums module and other blocks.

Now consider the possibility of hijacking. What if someone steals those cookies? Discuss it in this thread and see if we can come-up with any better solution. (Remember, PHPSESSIONID or your custom id cookie has similar issues).

Keep in mind followings:

1. I need to use autologin features from many computers (ex. work, home). This means there can be more than one valid saved autologin cookies.
2. User can be on dynamic IP.
3. UserAgent will be fixed for every machine, but someone who can steal cookies can forge this also. Changing UserAgent is even simpler.
4. There can be more than one XOOPS installed on the same site.

---

Cookies gets new lifetime when user opens the site before autologin cookies gets expired. Have we done it intentionally? Remember gMail asking password after 2 weeks no matter how frequently you visit them

Related to point raised by m0nty – I will assume that site administrators are educated enough and know the risk of autologin cookies. I can easily live with that. But if we want this implemented anyway – a very simple change will be required in /include/checklogin.php and one more constant in mainfile.php (hehe).

We should also try to move the XOOPS_COOKIE_PATH and XOOPS_AUTOLOGIN_LIFETIME into xoops_config table (if possible).

Thanks a lot for this! It runs absolutely fine! I'm greatful for this!

Myths about autologin + email hack

Myth1: It increases server and database load heavily because garbage collector will not be doing clean up. I can’t afford it because my concurrent user count is huge.

Fact: It will not increase the load any significantly. Query to xoops_session table will return few extra bytes and ‘Who’s online’ block will pump more uname(s). That’s it. XOOPS always creates a record for any new sessions (no matter if the session is anonymous or member’s). So query count stays same. And we see more realistic information in ‘Who’s online’ block and members can have pleasant browsing. I’m sick of seeing ‘no permission’ as my session gets expired while typing response (may be I should type fast – hehe).

Myth2: Oooo, is it safe? We can’t compromise with security B-).

Fact: It is far safer than storing username/password in the browser. Yes, it is little less safe than normal operation, but eventually it is exactly same logic what cookie based session persistence have. The only difference is – server can release resource as usual but you get a fake feeling of extended session using saved cookies. It will be transparent to end-user as server will create new session without authentication.

Assuming possibility of session hijacking, without this hack you are vulnerable during your current session only. But with this hack the period is extended till auto-login is valid. Big vendors like gMail (2 weeks), Yahoo Mail (24 hours) also use similar mechanism with similar risks.

Myth3: Cookies are saved on user’s computer. We lost the control

Fact: Site admin can invalidate all (or some) saved auto-login. Clear up actkey column in xoops_users table, done. Those save cookie is trash now.

Myth4: You guys are great, doing awesome things

Fact: The actual credit should go to XOOPS team who has done this great work. We are just tweaking the application to satisfy our personal urge and need. Sometime hacks are worth sharing in the community. So we come up aboard

I wish, I could get more free time and opportunity to contribute more

---

I’ll not advocate this hack to any critical site dealing with big $$$. But now many of us have critical site, so IMHO this hack is a MUST HAVE for most of people .

I also request XOOPS core team to consider merging this into main distribution. Ideally, a site parameter (entry in table xoops_config or mainfile.php) can be used to enable and disable the feature and parameters.

Cheers,

Quote:

Add it to the patch tracker at sf.net (see link in development block on left side). We can then process it for inclusion in XOOPS 2.1.

Herko

Could someone give more detailed instructions on the change needed to the mainfile to extend the time of the autologin.

The instructions state:
Quote:

Do you need to include the [ code ][ /code ]?

Where does this belong in the mainfile.php?

Thanks for your help.

Sorry for the confusion.

U just need one line added to mainfile (only if you are not happy with one week).

define('XOOPS_AUTOLOGIN_LIFETIME',2678400);

[ code ] and [ /code ] doesn't have any meaning in PHP context. It was added for newbb forum. See the background and border around the code in below line.



Cheers,
Sudhaker