Quote:
I agree. I've run into the same problem as some other folks in that people don't want to go to the trouble to log in. It seems like such a simple thing, but people really are that lazy. They'll read a post, but as soon as they realize they need to log in to reply, they make a cost-benefit analysis in their heads and say, "Maybe later." But, of course, when later comes around they forget about it.

Plus, some of the modules (such as the weather blocks) have significantly reduced value if the user can't just glance at the block upon going to the site without logging in first.

Hai Devs,

I like this issue also insite my XOOPS build in.
Whe you say this is becose of security reasons, i can understand, but wich one?

I'm not so known of this so please can you explane this a litly more.

Maby we can incrept the password nobody als can use it.

Thanks
Niels

I'm sorry when not al is written correct, my anglisch is very bad.

I think this is an important feature for many of the reasons previously mentioned. However, a built in solution has to be done very carefully. If you were to set a cookie that automatically logged you in, it would obviously need to represent an encrypted version of the user's id. The server would decrypt it, verify it, and log them in.

The problem is, this encrypt/decrypt algorith of sorts, would need to be unique to every server. Otherwise, you could encrypt the id on your own xoops, fake the cookie to another site, and voila! That is why it would be difficult to have a built it version. The algorithm would have to a custom/unique seed for every site and be still be hard to crack.

There are of course other ways to do this, anyone wanna brainstorm with me?

-ddFred

Well.. upon registration the admin could enter a key. The key could be used as a seed to encrypt the user string. Though I think the password stored in the MySQL database is a md5 hash of the password you enter on registration. So then the server doesn't even have your original password. I suppose you could also encypt the md5 hash of your password as well. Could be done, if you lose that key or change it all those cookies will be invalid. But I guess at worst is you'd need to login again.

I understand how this could be a security risk, but I think it should be an option for the site admin. I myself find it really annoying that I need to re login at xoops.org every time I visit it. The system at work and home are both my systems and are not public system. I'm aware of who uses my system and I know to logout when I finish. I know if that I set a cookie to keep me logged in at all times, that it'd be relatively secure. I think the trade off between security and convenience should be up to the site admin. I'd definitely want my users to be able to be logged in at all times. I'll risk some users who don't know better leaving their cookies on a public machine, if it'll convenience the majority of my userbase and promote user interaction/participation, then I'll opt for that.

The truth is that people are lazy. I've often found myself wanting to reply to something in these forums, and then find there's no reply button because I'm not logged in. Sure it only takes you only a few seconds to log in, but by then I think that my reply isn't worth the logging in time, or that I'll do it another time. Just look at the Who's Online module. Right now there's 5 memebers and 24 guests. I'll bet you that some of those 24 guests are just not logged in. Imagine the amount of members you'd be able to see online if you didn't force people to login so often.

I went to add another comment and couldn't find the reply button. Arrrggh! Why? I wasn't logged in again.

Yes, a nice long user entered seed during the install would work. And rather than using it to encode the user id, perhaps each user record is updated with a nice long (40 char+) unique string that is also put into the cookie. The version in the database could be encrypted like the password too, I guess. So the server sees the cookie, encrypts it, and tries to find it in the database. I would only be as secure as the person's cookies, but hey if you aren't using https nothing is secure in the first place.

that can by nice, when we insert a encoded ip adress insite the cookie blocks the use of the cookie from an other location.

i hope the XOOPS dev's conseder it to include this in it.

What method does invision forum use?

Quote:

Perhaps you could ask to Koudanshi because he adapted IBF to XOOPS V2 ...

If persistent logon is added please do not add a session ID to the URL.

The URLs are perfect right now in the NEWS section for EXCELLENT google spidering. Adding a session id would impact that ability.