Can Wiki integration handle subdomains

Get help from other users here.

Moderators: Developer, Contributor

Post Reply
TomR
Posts: 55
Joined: 01 Aug 2006, 10:22

Can Wiki integration handle subdomains

Post by TomR »

I tried to integrate Dokuwiki with our Mantis installation and followed de Wiki on integration.

However I have a problem getting it to work.

I suspect that the problem lies in the fact that both Mantis and Dokuwiki resides as a subdomain within our webserver.

Without the inte3gration instructions, Dokuwiki is working fine.

After integrating it does not work.

When I click the link, Mantis will take me to
http://dokuwiki.

But page stays blank.

Where does the name space come in and how is that related to the plugins directory where you have to make a subdir called <mantis> and put in a syntax.php.

Can some verify that it should work with both systems ( Mantis and Dokuwiki ) as subdomains.

Thnx in advance,

Tom
TomR
Posts: 55
Joined: 01 Aug 2006, 10:22

Post by TomR »

I investigated a little further and can now access Wiki. I had a problem while copying code to .php script.

My next problem is that I can not get into Wiki as a user:
Permission Denied
Sorry, you don’t have enough rights to continue. Perhaps you forgot to login?
I checked all files and contents from the integration document but cannot found any error or typo.

When I change to

Code: Select all

$conf['useacl']       = 0;
I get access ( anonymous I guess ).

It seems that the function

Code: Select all

auth_is_user_authenticated()
returns false in

Code: Select all

function trustExternal($user,$pass,$sticky=false)
in program dokuwiki\inc\auth\mantis.class.php .

I do not understand why because all authentication in Mantis is working correct.

Any ideas / hints appreciated.

Tom
vboctor
Site Admin
Posts: 1304
Joined: 13 Feb 2005, 22:11
Location: Redmond, Washington
Contact:

Post by vboctor »

You need to set the following configuration item in config_inc.php

Code: Select all

$g_cookie_domain = '.yourdomainname.com';
Note that dot before the domain name. This tells the browser to share the cookie accross all sub-domains for your domain name.

Hopefully this fixes the problem.

Regards,
Victor.
TomR
Posts: 55
Joined: 01 Aug 2006, 10:22

Post by TomR »

Victor,

thank you, that did the 'trick'.

Just a question about authentication, does Wiki only recognize the default role of a user, or the role a user has in a project.

I have a quest account assigned to 3 projects as VIEWER and 1 project ( TEST ) as a MANAGER ( also tried REPORTER and DEVELOPER and UPDATER ), however the default role is VIEWER.

I added UPDATER to acl.auth.php

Code: Select all

*       @VIEWER         1
*       @REPORTER       2
*       @UPDATER        4
*       @DEVELOPER      8
*       @MANAGER        8
*       @ADMINISTRATOR  8
*       @ALL            0
Tha account is not able to edit or create a wiki entry from that issue. It seems that only the default role is taken into account.

Can you verify that.

Tom
vboctor
Site Admin
Posts: 1304
Joined: 13 Feb 2005, 22:11
Location: Redmond, Washington
Contact:

Post by vboctor »

It should support the project-specific access level.

Code: Select all

      $t_project_name = getNS( getID() );
      $t_project_id = project_get_id_by_name( $t_project_name );
      $t_access_level = access_get_project_level( $t_project_id );
      $t_access_level_string = strtoupper( get_enum_to_string( config_get( 'access_levels_enum_string' ),  $t_access_level ) );
 
      $USERINFO['grps'] = array( $t_access_level_string );
If it is not working as expected, check that the $t_project_name is matching the name of the current project. It may actually be more reliable to get the current project using Mantis API, rather than extracting it from the Wiki page id.
xavier
Posts: 4
Joined: 25 Sep 2006, 07:57

Post by xavier »

I've got the same problem, the acces level in the wiki is not specific to a project and i've checked the $t_project_name it's matching the current project, how can I fix this?
thanks
Post Reply