Hi Mithrandir,

Please find hereafter:

- a summary of what have to be modified in common.php, cp_header.php, functions.php and checklogin.php (even this was already explained in my previous posts )
- a short list of recommendations for module developpers

Core file modifications

1. XOOPS_ROOT_PATH/include/common.php - around line 236 (Xoops 2.0.5.2)

Replace
Quote:
by
Quote:
... and modify the line 1 line after
Quote:

2. XOOPS_ROOT_PATH/include/cp_header.php - around line 9 (Xoops 2.0.5.2)

Replace
Quote:
by
Quote:
... and modify the line 1 line after
Quote:

3. XOOPS_ROOT_PATH/include/functions.php - around line 137 (Xoops 2.0.5.2)

Modify the xoops_refcheck function

Quote:

4. XOOPS_ROOT_PATH/include/checklogin.php - around line 76 (Xoops 2.0.5.2)

add the following "elseif" condition before the "else"

Quote:

Recommendations

In order to make XOOPS and modules available and working properly from behind a proxy (or other configurations allowing you to access your site from different URLs), you have to ensure that:

- you only use XOOPS_URL for simple HTML anchors or redirections
- All notification messages (system or modules ones) should be adapted to use a "default" domain name in links (to prepend to XOOPS_URL). This could be achieved by creating a new constant in mainfile.php - XOOPS_DEFAULT_DOMAIN or proposing a list of valid URLs(array constant in mainfile.php). This is mandatory because you never know from where a mail is read...

Examples:
mainfile.php
XOOPS_URL = "/mysite"; // or simply "/"
XOOPS_DEFAULT_DOMAIN = "http://www.mycompany.com";

php code snippet
$comment_tags['X_COMMENT_URL'] = XOOPS_DEFAULT_DOMAIN.XOOPS_URL . '/modules/'..........

Of course, if you defined a complete XOOPS_URL (current way of working today), you will have to leave XOOPS_DEFAULT_DOMAIN empty !!!

OK, I know you will ask me which system files have to be modified...
- mainfile.php (new constant)
- /kernel/notification.php, /class/xoopsmailer.php, /include/comment_post.php, /lostpass.php and /register.php => prepend XOOPS_DEFAULT_DOMAIN to all XOOPS_URL usage

OK, would you like the same info for some basic modules (NON exaustive - main examples => prepend XOOPS_DEFAULT_DOMAIN to all XOOPS_URL usage)?
News: look for STORY_URL and WAITINGSTORIES_URL in news/submit.php
NewBB: look for POST_URL, THREAD_URL and FORUM_URL in newbb/post.php and newbb/include/notification.inc.php
Download: look for FILE_URL, CATEGORY_URL, BROKENREPORTS_URL, MODIFYREPORTS_URL and WAITINGFILES_URL in /download/submit.php, /download/admin/index.php, /download/brokenfile.php and /download/modfile.php

And I repeat it:
THESE MODIFICATIONS ARE FULLY COMPATIBLE WITH CURRENT XOOPS BEHAVIOR.

I hope this will help. This is just a summary and you can always read the all story for details and justifications.

Benoit

Xoops 2.0.6 is out. Now I think it is time to wrap-up at least one important thing that should (must IMHO) be integrated in the next release.

When you have to setup an intranet website, you often need to access your website from different URL's.

Here are some examples:

-http://computername/xoops
-http://158.166.248.205/xoops
-http://www.intranetdomain.com/xoops (linked tohttp://dns_machinename/xoops via a proxy server)
-https://www.extranetdomain.com/xoops (accessible from the outside world - linked tohttp://dns_machinename/xoops via a proxy server)

All these URLs point to the same machine/web server. The 2 first ones do not imply the use of a proxy server. The third and fourth ones are proxy mappings.

Where is the problem with XOOPS ?

No real problems, just some bad uses of the XOOPS_URL constant. If you want to achieve the previously described configuration, you MUST use a XOOPS_URL without any domain information, thus use a semi-absolute url. With the previous examples, the XOOPS_URL constant must contain /xoops.

What does it mean ?

Mainly three things:

1. 3 system files have to be adapted (/include/common.php,/include/functions.php, /include/checklogin.php).

2. Module developers have to think twice when they use XOOPS_URL for other reasons that simple HTML anchors or redirections

3. All notification messages (system or modules ones) should be adapted to use a "default" domain name in links (via XOOPS_DEFAULT_DOMAIN constant? my solution today) or proposing a list of valid URLs. This is mandatory because you never know from where a mail is read...


I have a working version of XOOPS 2.0.5.2 running in production that implements the small system hacks described in this post (7 lines in three files !!!) that works perfectly well and is fully compatible with "full" XOOPS_URL.

Of course if you want to work with this configuration AND have working links in notifications, you will have to adapt other files (mainfile.php, kernel/notification.php, class/xoopsmailer.php, include/comment_post.php, register.php, lostpass.php).

For all other module specific notifications, you might want to adapt certain files. I have all this infomation available for those who cares.

THESE MODIFICATIONS ARE FULLY COMPATIBLE WITH CURRENT XOOPS BEHAVIOR.

Conclusion

My conclusion is: why wait to add it to XOOPS ? Would XOOPS be the first CMS on earth not working in an Intranet/Extranet configuration ?

I am fully available to help and discuss with Core members, if they finally react to my repeated posts. I fully understand that you are very busy guys ! You can count on me to help you. Do you need incentives?

Best regards,

Benoit

May I suggest you to use Filezilla as a Windows FTP client. It is, IMHO, the best FTP client available for Windows and it is GPL... It can "chmod", work through SSL or SFTP via SSH2 , and many more. I bought CuteFTP pro 2 yeas ago. Today, I have switched...

Benoit

The strange behaviors mentionned in my previous post came from the xoops_refcheck function (in /include/functions.php). All INSERT and UPDATE database statements was rejected.

This function is called from /include/common.php ("Connect to DB" code), /include/cp_functions.php (xoopsfwrite function) and banners.php (clickbanner function).

Its role and meaning are unclear for me (related to XMLRPC ?). Nevertheless I adapted the code to make it work with proxy (and thus "semi-absolute" XOOPS_URL, but also full one) while trying to keep the original idea.

So this is the new code:

Quote:


SUMMARY

To make XOOPS working behind a proxy and/or with the possibility to use a "semi-relative" XOOPS_URL you have to modify two files: /include/common.php (modify two lines as described previously in this topic) and /include/functions.php (see above).

I have, once again, tested the proposed solution in the following ways:
- direct access to the hosting machine - XOOPS_URL = full
- direct access to the hosting machine - XOOPS_URL = semi-relative
- access through a HTTP proxy - XOOPS_URL = semi-relative (mandatory in case of proxy usage)
- access through a HTTPS proxy - XOOPS_URL = semi-relative (mandatory in case of proxy usage)

All my tests passed succesfully (read/write normal operations for registered users + some read/write admin operations).

I would really appreciate to have some comments from one of the core developper. I think these modifications are really important and might be included in the new XOOPS version.

Thank you.

Benoit

Oups... watch out...

I discovered some strange behaviors in Admin tools (does not save new block in DB for instance) since I have changed the XOOPS_URL to a "semi-relative" path as peviously descibed. I will double check and update this forum as soon as I found a solution.

Ideas are welcome.

Benoit

Hi,

Are you using myXoopsForge modules onhttp://dev.xoops.org ?
I suppose that the answer is yes. Is it the "out-of-the-box" version or are you customizing it ? If yes, where could we found the adapted/patched version ?

I plan to install this module for an internal 900 people community and I would like to share experience on deploying/using myXoopsForge (in English !)

Thank you.

Benoit

Am I talking to myself ?

I found answers to all my questions !

First of all, there is another place where the "module name extraction" fails: in /include/cp_header.php (around line 9).
So you have to correct it the same way (cfr. previous post).

Second: I simply change my full absolute virtual path (XOOPS_URL in mainfile.php) to a semi-relative (or semi-absolute !) one.

http://www.mydomain.com/MyApplication => /MyApplication

Now, I have just tried to use my XOOPS application via 3 different means and it works perfectly well (just a bit slower through my SSL proxy )

May I ask to one of the member of the "dream team" (the core one !) to confirm my discovery and , if needed, to correct that bug in the 2 core files ?

Thank you !

Benoit

I finally found the problem and it is not related to the port number but simply to the way the module name is extracted from the requested URI that is particular when XOOPS installation is accessed via a proxy server.

It is around line 236 in /include/common.php (Xoops 2.0.5.2)

Quote:

It seems that this line extracts the module name from the requested URI. It works perfectly well when you have a direct access to the server. But once XOOPS is behind a proxy server, the HTTP_HOST is the real host (not the "domain" used to access XOOPS through the proxy) and so is different from XOOPS_URL => no module name can be extracted.

I do not really understand the reason why this "module name extraction" line has been written like that. It might be right...

I replaced this line by the following one



... and modified the line after



... to adapt the url_arr array index.

Am I the only one on earth that access a XOOPS installation through a proxy ????!!!!

I really don't know if this is the best way to do or if it is really a bug ! Anyway it solve my proxy problem.

I really would like to have a piece of good advice on the following point: since all links in XOOPS are build from XOOPS_URL variable defined in mainfile.php, you are only able to access you site in one and only one way. Am I right ? I would like to achieve the following: access the same site 1.directly (no proxy), 2. through an HTTP proxy and 3. through another HTTPS proxy. Do I have to write some code in mainfile.php to dynamically adapt XOOPS_URL ? Does it exist another mean ?

Thank you very much in advance for your answers.

Kind regards,

Benoit

I am going to start coding:

- I would like to add notification option for each TOPICS in the core News module. News module is already notification-enabled but only for Global events.

- I would like to make WF-FAQ multilevel (just finished) and enable notification (to do).

...but I have a couple of questions before starting :

- Are you aware of some hacks doing exactly that ? Or a current development ?

- Where is the best place to start ? Does I have to start working on the latest official versions or from a living CVS (if CVS, which one?) ?

- How can I share my work with others ? They are a lot of interesting things to add to the already very good modules. I would like to be able to update modules regularly to the latest "official" versions without having to apply many personal patches. So I would prefer to integrate my patches into official modules - only if there are good, useful and generic, of course! Perhaps a stupid question, but how to do it ?

I applied for joining the module development team 3 days ago and I am waiting for an answer.

Thank you very much in advance for all your suggestions: I really want to offer my services to people who have done such a great job that I will be able to start (in two or three weeks) a complete Intranet portal based exclusively on XOOPS for our internal IT community (more than 1000 identified individuals !).


Benoit

This is exactly what this hack is doing except that the user name (and password) is entered via the standard XOOPS form. If you want some help, try to be more precise: what do you want to do ? Identification or authentication ? Why do you need javascript ? You talk about Active Directory and then about Netscape Directory. How are there related ?

Few months ago I was also a PHP beginner... Put your hands in it and you will get it working ! But please, try to describe precisely what you want to achieve.

BM