[dokuwiki] Re: DokuWiki BugTracker: [LDAP] getUserData fails if no $conf[bindpw] (1053)
- From: Stephane CHAZELAS <stephane.chazelas@xxxxxxxxxxx>
- To: jacob.steenhagen@xxxxxxxxxxxxx
- Date: Thu, 14 Feb 2008 09:16:04 +0000
On Wed, Feb 13, 2008 at 10:26:45PM +0100, DokuWiki wrote:
[...]
> The following task has a new comment added:
>
> FS#1053 - [LDAP] getUserData fails if no $conf[bindpw]
> User who did this - Jacob Steenhagen (jake)
Hi Jacob,
I saw your comment (below) on this Flyspray task. I've
added another comment, but then thought it would be easier to
follow-up on the doku mailing list.
So here is my comment:
Jacob Steenhagen (jake) - Wednesday, 13 February 2008, 21:26 GMT:
[...]
> The basic problem is, by the time DokuWiki is to the point of
> doing this call to getUserData to find the email addresses of
> people who are watching pages, the users password is long
> forgotten. For example, consider the following typical
> workflow:
Hi Jacob,
that is not true. The password is stored encrypted in the
session cookie and can be decrypted by dokuwiki.
That is why for instance if you change your password in the LDAP
directory, doku logs you out and you need to reenter your
password.
[...]
> There are basically two different ways to solve this problem
> (not including putting my password in the cookie, which is a
> bad idea): 1. Define a "superuser" (binddn and bindpw) in the
> DokuWiki config. This superuser doesn't need to be super as
> far as Active Directory is concerned. I have an account I've
> used for this type of purpose on my AD for quite some time. It
> basically just needs permissions to read the directory (which
> any normal user account does).
[...]
That typically doesn't work for me unfortunately. I'm using the
company's Microsoft LDAP directory which I am not the
administrator of. I could use my userid except that our company
enforces us changing our password every now and then which would
mean updating the dokuwiki config every time.
Adding the checkPass() in getUserData() really makes it for me:
--- /home/stephane/tmp/ldap.class.php~ 2008-02-14 08:37:33.403308000 +0000
+++ inc/auth/ldap.class.php 2008-02-14 08:37:33.408308000 +0000
@@ -142,10 +142,15 @@
*/
function getUserData($user) {
global $conf;
if(!$this->_openLDAP()) return false;
+ if ($this->bound == 0) {
+ $pass =
PMA_blowfish_decrypt($_SESSION[DOKU_COOKIE]['auth']['pass'],auth_cookiesalt());
+ $this->checkPass($_SESSION[DOKU_COOKIE]['auth']['user'], $pass);
+ }
+
// force superuser bind if wanted and not bound as superuser yet
if($this->cnf['binddn'] && $this->cnf['bindpw'] && $this->bound < 2){
// use superuser credentials
if(!@ldap_bind($this->con,$this->cnf['binddn'],$this->cnf['bindpw'])){
if($this->cnf['debug'])
Best regards,
Stephane
> ----------
> I'm new to DokuWiki, so I don't speak for the original authors of this code
> in any way, shape or form... but I did just spend a fair amount of time
> digging into this problem on my local (brand new) install.
>
> The basic problem is, by the time DokuWiki is to the point of doing this
> call to getUserData to find the email addresses of people who are watching
> pages, the users password is long forgotten. For example, consider the
> following typical workflow:
>
> 1. I visit the main wiki page. I know I'm gonna do some edits, so I log in.
> 2. Username and Password sent to DokuWiki... ldap.class.php verifies me
> 3. I visit the page I want to edit
> 4. I click edit
> 5. I make my changes, DokuWiki looks up email addresses for anybody who's
> watching pages
>
> In that scenario, the only HTTP connection that contains my password is 2.
> The cookie that identifies me in sessions 3-5 does not contain my password.
> This is a very conscious security choice and I don't see that changing (at
> least, I hope it doesn't). So when we get to session 5 and DokuWiki needs
> to once again make an LDAP connection, it no longer has my password to do
> it with; therefore, the LDAP connection fails, DokuWiki can't lookup email
> addresses of people watching the page I edited and the email notify
> silently fails.
>
> There are basically two different ways to solve this problem (not including
> putting my password in the cookie, which is a bad idea):
> 1. Define a "superuser" (binddn and bindpw) in the DokuWiki config. This
> superuser doesn't need to be super as far as Active Directory is concerned.
> I have an account I've used for this type of purpose on my AD for quite
> some time. It basically just needs permissions to read the directory (which
> any normal user account does). It does not (and I'd recommend should not)
> have any sort of administrative privileges. Keep in mind that bindpw will
> be in plain text in a file on the web server.
> 2. Change DokuWiki so it has a cache of names/email addresses for every
> user that's logged into the server.
>
> Advantages of method 1:
> * Always the most current information.
> * Works right now without any code modifications to DokuWiki (I just spend
> a decent amount of time figuring that out!).
> * No chance of cache corruption or being out of date.
>
> Advantages of method 2:
> * Does not require any "superuser" type account. This may be AD specific as
> AD does not allow anonymous binds to search the directory.
> * Keeps the password to a valid AD account out of the plain text config
> file.
> * Reduces the load on the LDAP server.
>
> ----------
>
> More information can be found at the following URL:
> http://bugs.splitbrain.org/index.php?do=details&task_id=1053#comment2106
>
> You are receiving this message because you have requested it from the
> Flyspray bugtracking system. If you did not expect this message or don't
> want to receive mails in future, you can change your notification settings
> at the URL shown above.
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
- » [dokuwiki] Re: DokuWiki BugTracker: [LDAP] getUserData fails if no $conf[bindpw] (1053)
