Quote:

I think it's a security feature so maybe best left alone... that said, I can't be bothered to find out what it does (maybe stops php files being run from remote sites?)

I've had the same problem and have typed up an (potential) solution here:
https://xoops.org/modules/newbb/viewtopic.php?topic_id=45943&start=0#forumpost202503

Hope it helps.

P.S. This might sound a bit rude, but there are loads of threads about this subject so perhaps we could all reply to the one linked to above?

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. 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 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 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 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.

I'm sorry but I didn't quite understand that. Could you elaborate? Thanks.

Ta!

Anyone????

I'd quite like a module, somewhat like an articles/section/news module, but which allows multiple fields.

e.g. rather than a summary and main text, it would allow lots of bits of information.....

and was searchable e.g. title='XXX' & field3='YYY'

Is there anything like this available?

Thanks

Thank you very much for your quick reply.

Do you use Protector with XOOPS 2.2.3?

(I only ask becuase lots of modules don't seem to work with 2.2.3)

When I installed XOOPS I omitted to change the sql table prefix from "xoops". I now understand that, security-wise, I should have changed this.

How can I change this now, without re-installing? Is it as simple as
1. Rename the tables
2. Change the constant in mainfile.php

If so, what's the easiest way to do number 1?

Thanks.

(EDIT: I originally posted about how it might be that the content module had it's own text sanitiser, but it's early in the morning and it didn't make much sense.....)

I'd be interested in a solution too. I've had that problem too (ancient join-date, negative post count, and some other entries have been missing). I had to fix it with phpmadmin.