[pmwiki-users] authuser and ldap authentication - help needed!

[david roundell]

pmthanks for the reply. much appreciated!I tried your suggesstions - however this made no difference. login/logout changes to logout but the page does not display. the @ by itself was being picked up by the config which I've changed to the setting above. so now in authuser I have at admin: david, at editors: *, test,
ldap://name-omitted:389/OU=MANSERV,O=abc?uid?sub (the ldap server relevant to my setup.)
 
a random page attributes now being:
 
read: @nopass
edit: @editors
I'm running two wikis one with ldap the other without. both are in separate folders so technically do not conflict with each other. 
just in case they did I have given both a unique session name in their respective configs.
might it may be worth trying a fresh install of pmwiki? perhaps outside the web directory (I could always point iis to point to this as a virtual directory for dns to resolve).i'm unable to test outside of work as I would not get access to the ldap server. if I login as admin or test then authuser authenticates me fine.thanks for any suggestions.david
 
 
On 12 Feb 2009, at 21:05, "Patrick R. Michaud" <pmichaud at pobox.com> wrote:
On Thu, Feb 12, 2009 at 06:36:00PM +0000, david roundell wrote:

noticed today that when i try a 'secure' page that requires a user to

authenticate themselves that the name/password prompt reappears, even after

correctly entering the right username/password. you would think this is perhaps

a problem with 'talking' to the ldap server. however, the login/logout changes

to logout - so this tells me (i think) that the id and password have been

authenticated.

You're likely correct -- if the login/logout changes to 'logout',
that's an indication that the person is authenticated and something
else is happening.



the attributes on a random page are:



read p/w: @ id:*

edit p/w: @ id:*

The bare '@' looks very odd to me -- it might be causing
an issue.  Normally to restrict access to authenticated
folks I would expect   "id:*"   with no @ .


the page siteadmin.authuser has @editors: id:*

Inside of SiteAdmin.AuthUser the groups already assume "id:", so
this should probably be  "@editors: *".  If you're using groups
in this way, though, you probably want your read/edit passwords
to be "@editors".

Pm



From: roundelld at hotmail.comTo: pmwiki-users at pmichaud.comSubject: authuser and ldap authentication - help needed!Date: Thu, 12 Feb 2009 18:36:00 +0000

hello using pmwiki at work and was able to successfully authenticate users via ldap. this is a great help!noticed today that when i try a 'secure' page that requires a user to authenticate themselves that the name/password prompt reappears, even after correctly entering the right username/password. you would think this is perhaps a problem with 'talking' to the ldap server. however, the login/logout changes to logout - so this tells me (i think) that the id and password have been authenticated. the attributes on a random page are: read p/w: @ id:*edit p/w: @ id:* the page siteadmin.authuser has @editors: id:* config has ini_set('session.gc_maxlifetime', 3600);$AuthUser['ldap'] = 'ldap://name-omitted:389/OU=MANSERV,O=abc?uid?sub';include_once('scripts/authuser.php'); and authuser.php has been amended to search the entire name directory function AuthUserLDAP($pagename, $id, $pw, $pwlist) {if (!$id) return false;if (!$pw) return false;if (!function_exists('ldap_connect')) return false;$fullUser = $id."@net.name-omitted.co.uk"; the only recent change was a dns entry was created so the servername during testing went from http://abc-123/xyz to http://abc-xyz - the content in the folder remained static as did permissions. any clues/directions/pointers as to why the page does not display the content even with correct user id/pw? i can sign in using an admin id perfectly fine. obviously this is not desired for users! thanks for any help! david   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090217/402f1c9e/attachment.html