Hi,

I have re-launched my site, and have a lot of users saying they can't log in. They even say that getting the password reset doesn't work. Whil I'm not 100% sure of what errors they came accross, I tried and here is what I got from a few test accounts:

The passwords work on some test accounts and not others. There is nothing differentin the database between the accounts, save the name.

No matter what account, when I try and get my password reset, it gives me the "HTTP_REFERER" error page. However, it still sends the new password to the email, but the new password doesn't work.

So I disabled the HTTP_REFERER check which looks like this: Quote:... but it still gives me the "Why am I being directed here?" page!

Can someone please help?

I remember I got that error and I disabled my Windows firewall and then it went away, so maybe you have some sort of port blocking or script blocking going on.

Also, my XOOPS installation is running on Fedora Core 4, and there is something in that distro called "SELinux" where it is basically a hyper secure installation than a "normal" one....

I also disabled that when I was have those problems as well and it automagically cured itself.


Hope this helps...

Thanks, but no I don't have any additional security on the site (having trouble with the stuff that's there!) and I switched my firewall off, but it still doesn't work.

I understand the HTTP_REFERER has something to do with the url, like if details are kept in the url, just like with the banner clicks. It's the same with resetting your password....

coops wrote:
Quote:

sorry for laughing coops but I really did laugh, I spilt my coffee

Have a look here dude > HERE
and > HERE

Good Luck!

Quote:

Yeah it is a real bugger of a problem.

You mentioned
https://xoops.org/modules/newbb/viewtopic.php?topic_id=45345&viewmode=flat&order=ASC&start=10
https://xoops.org/modules/newbb/viewtopic.php?topic_id=45977&viewmode=flat&order=ASC&start=20
There's also
https://xoops.org/modules/newbb/viewtopic.php?topic_id=40151&viewmode=flat&order=ASC&start=10
And my old post
https://xoops.org/modules/newbb/viewtopic.php?topic_id=44044&forum=20&post_id=201268#forumpost201268
all on the same topic, and probably there's more.

Some people seemed to be coming to the same conclusion as I did (see my last post). This is just an elaboration of my last post. I had initially blamed the autologin hack, but I now think it's a more general problem with XOOPS 2.2.3. There may be other causes but I hope this helps some.

PROBLEM 1

I too had thought my site worked perfectly, until I got other people to look at it.... I had emailed them with the WWW version (e.g. http://www.website.com) of the site.

But the XOOPS_URL constant was non-WWW (e.g. website.com) This confused the cookie thing on their browsers and led to the "Why am I being redirected here" page. A cookie only works for a WWW or a non-WWW address, not both at once.

The reason *I* hadn't noticed the problem was that I was consistently using non-WWW (website.com) including on my bookmarks, and XOOPS_URL was non-WWW, so everything matched up nicely.

So I changed the XOOPS_URL to include WWW at the start, thinking that it would solve the problem. And so it might, but it depends on your server settings.....

PROBLEM 2

The next problem was that the server was set up to automatically redirect any requests to the non-WWW version. This too caused the same problem - but, this time, the other way round!! i.e. XOOPS_URL was WWW but the REAL URL was non-WWW. Note that it only caused non-WWW for the first page. As soon as you clicked a link it returned to WWW (becuase of XOOPS_URL).

The first thing I did to work around that was to remove the ability to log in from the first page. This did solve the problem as by the time the user gets to the 2nd/3rd page it is WWW - as is XOOPS_URL - so the whole thing matches. However, you probably want to be able to have the user log in first thing, from the home page.

To fix the problem finally, I got the bloke who owns the server to set the server default name to the WWW version. This means that if you type in http://www.webpage.com it DOESN'T go to webpage.com any more, it just behaves itself as it should. So it matches up from the 1st page, and I could put the log-in back onto the 1st page.

Phew... finally the XOOPS_URL constant (and therefore all the links within the site) and the server's default name matched, so no more "Why am I being redirected?" problems..........??? (It wouldn't have mattered if I had decided that I wanted to use non-WWW instead, as long as it was consistent).

PROBLEM 3

But... there is ONE final problem. This is that if anyone has bookmarked the site from BEFORE the server stopped redirecting to non-WWW, then they will be asking for webpage.com. In this instance, webpage.com will remain until a link is clicked. This is the same problem as mentioned above (but now it ONLY applies to people who have bookmarked the site - or type it in non-WWW). This could explain why the bloke with the one user (in a previous thread here) still had the problem after it seemed to have been fixed.

To get round the last problem I have kept the log-in off the 1st page, as I quite liked it that way (I have elaborated on the userform.html template so that it's quite helpful). Alternatively, you could (1) change the server to redirect ALWAYS to WWW (apparently you would need to setup two virtual hosts, the non-WWW one redirecting to the WWW one) - (2) email your users to update their bookmarks or (3) update the error message to say this.


SORRY FOR THE LENGTH OF THIS POST and the "Teach Granny to suck eggs" approach!!!!


EDIT:
P.S. I think the referrer checking is a security thing, so it might be unwise to remove it as some have suggested (?)

P.S.2. I've just noticed that Beavis had asked HOW to stop the server redirecting from http://www.website.com/directory to website.com/directory. I'll find out and get back to you. But perhaps you could ask your hosting company/bloke who owns your computer (unless it's yourself ) I think this is the principle, but I'm #OOPS#ed it if I could do it. You need to set up http://www.directory.website.com and get it to redirect to directory.website.com and get your public domain name to map onto that if relevant.

Frig me it's late.