Lost authority to edit my own project

this was actually intentional, since we (the security team) think this module is a bad idea. dww wanted to make sure you couldn't remove his warning notice.

A) It's just standard practice for the security team when we add warnings like this to lock further editing.

B) That shouldn't prevent you from creating releases.

C) If you knew "The module is insecure by design" in the first place, but you uploaded the code, and created a project node without bothering to state that from the beginning, how is the security team supposed to know "Of course I was going to give a proper warning about it."? In the vast majority of cases, contrib authors aren't as security conscious as we are, and it's our job to help protect the Drupal community.

"To assume else before I had written a summary or even made a branch reflects poorly on your assumptions of and trust in the Drupal contributors." -- You took the time to create a project node. How hard is it to write "This is insecure by design, don't use this on a real site" when you created the node? Whether or not you created a branch or a release is irrelevant. You posted the code and made a project node to tell the world about it, and you didn't provide a proper warning, so we did it as soon as we saw.

D) Meta: (not personally directed at you at all): It's basically the job of the security team NOT to trust Drupal contributors. ;) That's what we're here for.

Cheers,
-Derek

p.s. If you agree not to remove the warning, we could let you edit the node again.

Hi Derek,

Tobias created the Autologin project in order to contribute code we (imBridge) wrote for a client. It would appear that the purpose of the module and its intended use was never clearly communicated by us. We’d therefore like to clarify our thoughts and intentions regarding Autologin.

Autologin was developed for a specific purpose with security concerns in mind. Our client has requested to have a form created for a survey they’re running. One of the requirements was to have user-specific login details while the same time not requiring a traditional login by entering username and password into a form. Every respondent was to be emailed a link that would lead to the survey itself. After the survey is completed the user cannot retake it rendering the link itself useless.

Given these requirements, an insecure design that reveals user credentials is implied, if not required. To addess this we set up a separate Drupal site to host the survey which we then locked down limiting user access to the bare minimum. We developed Autologin as a way to pass username and password through the URL. Autologin links can only be created by someone who can alter user account passwords.

As the security team noted, Autologin links expose passwords through plain-text emails, they can be read by people reading over the shoulder and they are visible in the Apache access log. After deliberations we decided to consider this reasonable for the purpose user accounts are used in this particular application. This was a clear case of weighing ease of access with security and given the design requirements, ease of use was considered more important.

Autologin should only be used in cases such as this and with the potential security issues in mind. We think it is important to clarify the implications of using it and that it’s not for everyone and every site. We agree with you and have no intentions to remove the security warning if we're given permission to edit the project page.

To further address the issue of security we’d also like the module page to describe cases when it’s suitable to use Autologin and when it is not. Furthermore, I can be made co-maintainer to make sure the module description stays sufficiently clear and concise. Another idea is to make it possible to generate Autologin links with the module and only allow auto login for URLs that have been generated that way, preventing Autologin to work for accounts the site administrator hasn’t chosen explicitly.

Cheers,

Jakob Persson (solipsist)
imBridge

Slightly off-topic--a d.o redesign idea. Perhaps the security team should get a special field on project content types for notices such as this. With the d6 version of cck, the content_permissions module could be used to lock that field for use by the security team only (and it could get special attention-getting css styling)?

I restored edit rights. I'm on vacation and don't have time to further discuss this module's proposed use-cases and security implications, but so long as you keep that warning in there, feel free to edit the page again.

Cheers,
-Derek

The use case described doesn't justify putting username/password into the URL. There are still at least two ways to tighten up this module, but they are off topic for webmasters queue. I've posted some initial thoughts at "safe" (or safer) autologin module in the groups.drupal.org security best practices group.

In my opinion, the autologin should have been removed, in favor of the HTTP authentication (http://drupal.org/project/httpauth) module, which uses established standards, and you can use http://username:password@example.com/node/7 (as safe as a $_POST request (except for screen readers, co-workers etc...), also will work with all url's) instead of the much unsafer http://example.com/username/password