Plans for 7.x?

Is there any plan to releases this feature for Drupal 7.

Currently i am using for drupal 6 and planing to upgrade to drupal 7 but i dont know how to enable Windows domain based web-server authentication in drupal 7.

Here is a very rough 7.x version based on the 6.x development (downloaded on 2/15/11).

I wasn't too concerned with Drupal-approved formatting and comments, but I think I got the basics in.

It fulfills the requirements of automatically creating user accounts. I have also added options to disallow changing usernames and passwords, because our authentication stack is Drupal->Apache->LDAP.

There have also been a few edits to prevent duplicate item errors in the user table for users who were already in the system to begin with.

Hope this helps some folks.

that zip appears to be empty.

YEAH it is Empty Zip

Whoops.

Here is a real zip file.

The webserver_auth.module-0 is the original 6.x code in case anyone wants to make comparisons.

Sorry.

I wanted to check in and see if anyone had run into an issue with user creations with the Drupal 7.x code of this module, where dblog throws an error about the uid not being set? The issue resolves itself if the dblog module is disabled. After the user is initially created the dblog module no longer throws an error (because uid is likely set). If this is best placed into a bug report, let me know and I'll create it, but since 7.x isn't officially supported by this module I figured I'd drop the issue into this thread instead.

The error looks like this:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'uid' cannot be null: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:6:"Notice";s:8:"!message";s:21:"Undefined index: mail";s:9:"%function";s:11:"user_save()";s:5:"%file";s:43:"/var/www/traindesk/modules/user/user.module";s:5:"%line";i:567;s:14:"severity_level";i:5;} [:db_insert_placeholder_4] => 5 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://10.6.204.248/traindesk/ [:db_insert_placeholder_7] => http://10.6.204.248/traindesk/?q=user/1 [:db_insert_placeholder_8] => 10.6.12.18 [:db_insert_placeholder_9] => 1299181897 ) in dblog_watchdog() (line 155 of /var/www/traindesk/modules/dblog/dblog.module).

Thanks for the 7.x version code. I just put together a site with it, and it was exactly what I was looking for to work with Kerberos on an internal site.
-Justin

Useful module. I'll just add my voice to the call for this.

Should we consider a change of maintainer or a fork of this module?
It looks like boilermaker.jb1 hasn't worked on it for a couple of years and hasn't replied to this thread.

My place uses this module for our intranet site and we will eventually want to move to d7.
While I would prefer to not be the module owner, I can code PHP and would be able to help out with testing, fixing bugs, etc as a co-maintainer. I had hacked the drupal6 version a little to better support an internally authenticated admin user, but my code is not compatible with drupal7. I'll need a bit more experience with drupal7 modules to get it working.

Thoughts about all of this?

I would welcome a co-maintainer. I apologize for my tardiness in replying to this thread. I've been swamped for the past 6 months. I am going to take a look at some code that is supposedly 7.x compatible this weekend and start a development 7.x branch

That would be great; I also was looking for the 7 release.

This is a version I cleaned up a bit of the above file, but I still have dblog disabled

hi,
i have updated the "webserver_auth" (drupal7 version), in order to add a cookies based authentification
(and also the previously based webserver auth).
the cookie name is upgradeable in settings
i attach, in order to test...

Thank you D7 version contributors a lot! I improved Robert's (#12) code a bit in case domain user supplies correct credentials to server but is missing from drupal userbase. In that case uid is set to 0, i.e. anonymous and he can log on whatever he wants to.

EDIT: Oh, I just recognized it fixes the bug jgleicher (#6) mentioned.

All,

I took the expanded ZIp from #5 and then copied in webserver_auth.module from #13. I can enable the module and configure email domain and such, but Drupal accounts are not created from REMOTE_USER. I get 'Webserver authenticated user does not exist in drupal userbase" (line 64). I am not seeing a specifc configuration setting for auto-creation. Does it exist or should this be default behavior? I tried switching "Who can register accounts" under admin/config/people/accounts, but that doesn not seem to matter, nor does disabling user login block.

I seem to remember that I had to manually add 1st user in this module under D6, but thought I would ask first.

Jim

I can confirm what geste is seeing. I took the same route and I am able to login with webserver auth just fine if they already exist as a drupal user, but it is not automatically creating users. I'll dig around in it a little more and thanks for everyone's work in getting this to this point.

Quick question that I hope someone can help me with.

I'm trying to use Webserver_authentication and LDAP Authentication. Yes, I know that they're renowned for not working well together, however they've been working absolutely fine for my needs except for one minor issue.

When a user logs into our Intranet, then their email address is updated to be their username + @usa.redcross.org by webserver_auth, even though I've updated the email field setting in the module.

If I disable the webserver module, then ldap takes care of the rest and updates their email correctly. So I guess I'm asking if anyone knows how to either stop webserver_auth from updating the email address?

Subscribe

Hi guys

I've taken the version of the module file from #13 and the package from #5 and added the option of automatically creating a user in the Drupal user table if the user doesn't exist yet. The user is created using the e-mail domain from the settings in the role "Authenticated user". I've added a setting to the settings screen to enable this so you can choose if a non-existing user is created or treated as "anonymous".

I've also cleaned up formatting of the code a bit to make it adhere more to the Drupal coding standards (removed a lot of whitespaces)

Cheers, Martijn

Hi!

I recently installed a clean Drupal 7.4 enabled the latest version of the Webserver authentication found in comment #18

And when I try to access the site using a fully authenticated kerberos client I get the following error message:

Error message
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'jjacobsson' for key 2: INSERT INTO {users} (uid, name, pass, mail, created, access, status, init) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] => 3 [:db_insert_placeholder_1] => jjacobsson [:db_insert_placeholder_2] => $S$CS5bs4EQIz1KN1ip/HjRgmrWCrhiTWgigOXN6239kZC7vrhUZakN [:db_insert_placeholder_3] => jjacobsson@printley.int [:db_insert_placeholder_4] => 1310566786 [:db_insert_placeholder_5] => 1310566786 [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => jjacobsson@printley.int ) in drupal_write_record() (line 6859 of /var/www/drupal-7.4/includes/common.inc).

The account jjacobsson is created and looks pretty ok, except that the email looks a bit weird when I edit the user profile. (jjacobsson@PRINTLEY.INT@printley.int)

If I uncheck the "Automatically Create user when user does not exist in the Drupal user table" the error message disappear but it will not authorize.

Does anyone have any suggestions what to do?

Best regards,
Jocke

The username you use is probably the e-mail address? The way we login at my compony is using a username only, so my version of the module (the one from #18) doesn't take into account that you use a full e-mail-address as the username. That's why you see that the "@printley.int" is added to your username (which already contains the "@printley.int" part). We could change the code so that it checks if there is already a "@xxx" part or that you can enable/disable the automatic adding of the "@xxxx" part to the e-mail-address.

I don't see how this can be related to the authorization not working though...

Hey,

I tried using the version from #18 but it seemed to be causing problems which I think are because the removal of the prefix and suffix was only happening when the user was first registered. I have added that to the username check too. File attached.

Tom

You might wanna do something with the language variable when creating a new user as well, since I set it to "NL" in code, which is fine in our situation, but not the way you want the module to act for the community.

Default language selection added and change to the creation of the user object when user first logs in. It was using user_load() but now uses user_login_submit() which is, I believe, the recommended approach.

Ok, init function basically rewritten, it seemed to be doing stuff it didn't need to and all login functions now using the D7 recommended methods (I think).
The cookie stuff has been removed. Why was that needed? If someone can enlighten me I'll put it back in but it seems to me that Drupal manages all that side of things so better to let it get on with it.
This is now working for me but I will continue to post any fixes / changes as and when. Is anyone else actually using this on D7?

Tom

I do on my intranet site.
I use an older version and needed to insert drupal_goto() after authentication because without it user can not see a cached content on the front page. Will test your latest version.

Thank you for sharing your work!

@Thomas: we are going to use it for our intranet site (D7), since all other legacy applications also still use this method for SSO. Hopefully we can migrate to using the AD instead in the near future... The version I posted earlier already worked for us, but was far from perfect so I'll give your version a try soon. Thanks for sharing the results of your work!

Although this is working fine for me there is a major issue I have discovered. The first time a user either logs in or their account is created their permissions are not assigned. Or at least that's how it appears. In fact they are (checking the $user object reveals the roles have been loaded) but the node module doesn't appear to be aware of them. My working theory on this is that because that module is already loaded and has queried the permissions it thinks the user doesn't have any. I tried moving the code from hook_init() to hook_load() to no avail.

The problem only occurs the first time a user logs in and they will usually be navigating to the home page to view content so a simple workaround to this is to make all content viewable to anonymous users (under permissions) and since the web server is protecting the site, truly anonymous users still won't be able to see it (because Apache will block them and issue a 403)

Every subsequent page uses Drupal's built in user system to maintain the login and therefore works fine.

Any suggestions on how to fix this welcome.

Tom

Am i understand you right - when user logs in, he is seeing "access denied" instead of front page content?
If so, there is a workaround. It happens because webserver authentication is executed by the "init" event.
When this event happens, cached content permissions are not checked.
To overcome this behaviour i added an unconditional jump to a front of site - drupal_goto() - after user credentials are confirmed in the webserver_auth_init() function of this module. Not ideal, but works for me.

Can this be branched into a 7.x development branch? It will make it more apparent there is development underway for Drupal 7 on the module page.

I'm upgrading from 6 to 7, assuming I can get this module working.

@deaDleSs balLoon - I figured that was the way to go and have been wondering how easy / hard it would be to get the drupal_goto to use the requested URL instead of just the homepage. I will add this when I have time.

@smsearcy - It should work apart from the first login "access denied" message as described above. I'd be happy to maintain this in a 7.x branch, only reason I haven't is that I have no idea how. Do I need permission from the original developer? I guess I should just RTFM right?

@cwrstl - To run this with no code modification you just need to populate the authmap table. That should be easy enough as there are no complex fields and I think you can just copy the entries from the user table. re. point 2. The logout link simply doesn't work. The reason for that is that Drupal uses sessions to keep you logged in and the logout link will cancel the current session but it will also load a new page to confirm this and at that point webserver_auth kicks in and uses the username submitted as part of the HTTP request (this is automatically submitted for every page by the browser) and therefore logs you straight back in and creates you a new session. I think there is an option somewhere to remove the logout link? No idea why Safari should behave differently, perhaps it doesn't automatically submit the user's login details with each HTTP request and only asks for them now because they are being requested by the web server again? Presumably Chrome just remembers them and submits them again automatically. Even that doesn't quite make sense as it's the webserver that asks for the credentials and I assumed would provide them to Drupal regardless. This could probably be fixed by adding to the logout procedure or detecting that it had just happened but I'll be honest, I have no need for a logout link on the project I'm working on so unless I become the official maintainer I'm just not going to do it! Feel free to submit a new version!

Tom

Could you give an example of this and where it goes in that function?
Is it something like:
drupal_goto( 'user/login',drupal_get_destination() );

????

Is a full release of this for 7.x still in the pipline or are we going to have to bodge something together still to get this to work?

I *think* we need to add the following line:

drupal_goto(current_path());

to replace the call to attemptLogin() on about line 56 or so. In the try block. It should be the last thing it does and it shouldn't need the return then either I don't think. Problem is I don't have access to the network I was testing this on anymore! So, I've put that change in and attach a zip of the complete module. If somebody could test this that would be amazing.

The bug only occurs for a new user when they visit the site for the very first time. What should happen is that they are logged in and can see all content. What has been happening is that they get a "permission denied" message.

Note: I have also standardised the function names in this version so they all have the webserver_auth_ prefix.

7.x beta now available on project homepage. Thanks everyone for your contributions.

The issue here with the user receiving access denied on the first page request after logging in via the webserver is likely a result of changes in the hook ordering in D7. In D7 there are a multitude of things that run before hook_init(), and one of those is the menu access callback function which determines user access. When the page is refreshed, the user has access because by that point the user is saved in the session and the menu access callback passes. I ran into this same issue with Cosign module, which you can look to for reference:

http://drupal.org/node/1540268

I've created an issue for this:

http://drupal.org/node/1903896