Yep, you guys are correct.

For anyone who's interested in the details... the "could not insert forum post" arises when there is a database error. One common cause of a database error is not having a connection... but this would cause other things to fail. The other common reason is this HTTP_REFERER check. As a security precaution, whenever you submit a form, XOOPS checks whether the HTTP_REFERER is the same site, and if so, allows update/insert/etc... database privileges. If the referer is not present or different (often due to a firewall), then the database is given only permissions to do 'SELECT' queries. Any other query results in a DB error, and hence the error message.

Thanks for the correction.

Are other users having this problem? Sounds like it could be a database issue...

Just going out on a limb here... I don't really know anything about IIS, but from a quick google search it seems that IIS has 'SCRIPT_NAME' but not 'REQUEST_URI'. It looks like the XOOPS code should properly handle this. But if IIS is setting REQUEST_URI *incorrectly*, then this could be messing things up.

Could you guys try replacing (in include/common.php):

$xoopsRequestUri = @xoops_getenv('REQUEST_URI');

with

$xoopsRequestUri = @xoops_getenv('SCRIPT_NAME');

Please let me know if that works, and, if so, I'll try to find a more permanent way to integrate that into the XOOPS distribution.

It is possible, I suppose. Doubtful though. What browser are you using? XOOPS using the 'meta refresh' feature to automatically jump to the next page. If you are using a browser where this is not implemented correctly (e.g. strips off arguments from URL) then it could be the problem. But i'm not sure that any browsers have this problem.

The other problem could be in include/functions.php, function 'redirect_header'... There is a line where it determines the current page url for jumping back after login, for example. It uses $xoopsRequestUri, which is computed in include/common.php. If your server is not setting certain variables REQUEST_URI or SCRIPT_NAME properly then that may also be the issue. What is your webserver? If possible, is there any way to do some debugging with include/common.php and print/echo out the value of $xoopsRequestUri for a few example pages? This would be helpful to determine if that is the source of your problems.

Just out of curiosity, do you have problems with *other* redirects on the site... e.g. after posting a comment on something do you get redirected back to the proper location?

Regarding the customizable user page... while I think this would be nice for some sites, I don't think it belongs in the core. e.g. A corporate site that uses XOOPS probably has no desire to let users have their own homepages and is mainly interested in posting their own content for their customers. To me, the current homepage is useful enough as is for looking up contact info and searching for old posts (when you remember the author but not the thread title). As was suggested, I think a module would be the way to go for this. I don't know if such a thing exists, but perhaps you could use a wiki module in the meantime to provide customizable user homepages.

Just my 0.02

Quote:
Other than the needed extra data "cleaning" that is needed to allow HTML code in posts, this has always been my other reason to *not* want an html editor. For a community board maybe it is nice to allow people to change font color/face/size (??), but I don't think the result looks that great... and on a corporate support forum it will look extremely unprofessional. That leaves only 'bold', 'italic', 'heading', 'img'?, 'link', etc... The BB code already covers most of this in a very simple manner. There is also the 'color' code which is good as an alternative way to emphasize text, but it could in theory be abused. IMHO, the 'size' code should be dropped in place of a 'heading' code (possibly 2-3 levels worth of different styles).

Just to put a general question out there... what are the main difficulties with the BB code editor right now? IMHO, it doesn't seem any more difficult than HTMLarea to use. I usually just end up typing in the codes by hand, but I come form a programming background so this makes sense to me. Also I find typing the codes much faster. But what do others think? What is lacking and what makes htmlArea such a *great* alternative?

To make the editor 'configurable' (e.g. make certain tags/codes allowed or not) will bring up the same security issues as have been discussed with the htmlarea. The security threat here though is only the 'look' of the site, wheras with html could be far worse.

Just to reiterate... it doesn't matter how limiting you are with your editing controls (e.g. stripping out most of buttons on htmlarea or whatever), there is always a risk. You cannot assume that someone with use *your* form to enter their post. An attacker can easily figure out how to make a local copy of that form, remove all the restrictions and send *arbitrary* HTML to your server.

i.e. the HTML area has all kinds of controls to set a field "content" which gets sent to the server when the form is POSTed. If using the HTMLarea then the things that go into that "content" field are controlled. If an attacker finds another way to set that "content" field (actually quite easy), then any security that the HTMLarea offers has been circumvented.

The security needs to be handled on the backend, and that is currently what is lacking XOOPS 2. Right now you can either 'enable HTML' or 'disable HTML'. The only way the htmlArea would be useful is if you 'enable HTML' for all posts. But because the backend does *NO* real tag checking, this will allow an attacker to upload arbitrary HTML to your server.

Anyways, not trying to say it is not worthwhile. I'm not sure it is 'necessary' to support this, but it does seem that more and more people want it. I'm just trying to point out the security issues are not as simple as many people think.

Quote:

Nope, that's the latest. BTW, you can always check for yourself at the oneline cvs viewer at sourceforge:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xoops/xoops2/

Immediately after logging in (and just prior to the error message), what is the URL in the browser? Is it something like yoursite.org/modules/newbb/viewtopic.php with no additional arguments?

If it flashes by too quickly, try extending the time before redirect (modules/newbb/viewtopic.php):

Quote:

Change the '2' to 5 or 10, temporarily. Or alternatively, turn of 'meta refresh' in your browser.

One last thing: does your copy of moduels/newbb/viewtopic.php contain this line (near the top):

Quote:

Olorin and mike--h,

Very good points. I agree completely about making sites accessible; not only to people with disabilities, but also to people with older browsers or with browser features (e.g. javascript) turned off. And I agree that XOOPS news a little work with respect to the last one.

As for user-selected themes, it had never occurred to me that choosing themes might be for *accessiblity* reasons. Ideally CSS is supposed to solve such problems allowing a website to rely on browser default settings for font-size, etc... and to allow the webpage to be rendered on WAP devices or voice devices. In practice that is a huge amount of bother, people don't know how to do it, and even if they did, many browsers don't support complex CSS (layout, etc.) very well. Until we get to that point, maybe user-selected themes are a good intermediate.

Definitely some food for thought.