It worked! You rock!

Now the real test is seeing if the pictures will actually upload....

Thank you! Why didn't I think of that....

Quote:

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

What method does invision forum use?

okay I started this thred about a week ago about the page just reloading when when clicking the add album thing. well I figured it out.

I set the permissions on the 2 folders in the cache folder modules/xoopsgallery/cache/albums
and
modules/xoopsgallery/cache/tmp

to 777 and it created the album. I am now testing it to see if the rest works if not will post here..

hope this fixes your problem as well relish

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.

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.

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.

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.

The module-wide cache was already turned off, and debug mode is on, but the page still seems to be reloading onto itself.

Example from Website

If you click "new album" it just reloads.

Major frustration... I'm not sure what else to do, here.

Also, it's not as much of an issue, but in the Admin Menu, if I click on the gallery "banner" that's on the left side, it does a similar reload onto itself. However, if I mouseover and click on "Preferences" from the box that pops up, I can go into the prefs just fine (but as soon as I save, I get an error). It says the database is updated successfully, but when it tries to go back to admin.php?fct=preferences, it tells me the page is expired.

I think that's a completely separate issue, but wanted to post it just in case.

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