Jump to:
| Project: | User mailman register |
| Version: | 6.x-2.1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
I'm trying to get this module to work with a modified authentication for Mailman.
Here are the modifications I'm aware of:
- The login form uses a password INPUT field with a name different than 'adminpw', and has a few more hidden INPUTS.
- The paths to the standard Mailman admin pages are different (for example, URL for the main admin page is https://example.com/manage/list/admin/example-list@lists.example.com/gen...)
- Some fields are named differently. Example: the textarea for unsubscribe addresses is named 'addrs.addrs_text', the Unsubscribe checkboxes at
members/listare named like 'grid.unsub_YS5kb2xhbkB5YWhvby5jb20='. (maybe this due to Mailman version?)
So, I'm wondering if you'd consider rolling in a patch if I could get one working. If so, any insight on the following would be very helpful.
I was told by IT Services that the UMR script would have to accept cookies to get past authentication, so I'm trying to better understand the UMR process to test if this is actually required or to figure out a way around it. Does UMR actually "login", or does it send individual command REQUESTs to the Mailman admin URL bundled with the login pwd?
I've tried changing the name of the INPUT in the script and adding URL REQUEST additions for the other fields, but it didn't work (it wouldn't save the settings when I entered the URL to activate the list).
I'm thinking additional configuration settings for:
- HTML name of login password INPUT
- Additional REQUEST parameters (or something functionally similar) to account for custom fields in the authentication form
- Custom path modifiers for the various admin pages, if necessary.
- Custom INPUT name substitutions?
Thanks in advance. I'd love to make a donation, but I'm not getting paid for this project either, so all I can offer is code.
Comments
#1
UMR sends individual GET requests as described here.
In the standard mailman versions (at least on those i tested), this syntax let to bypass cookies so that UMR don't need to manage them.
In general, what you need to care of in UMR with a customized mailman version is:
1) The path after the "http:///mailman/admin/" string (this string can be set in the list url setting) because it is hardcored (look for the "drupal_http_request" calls to find where).
2) The name of the INPUT fields (if they are crypted as you said, you need that UMR uses the same cryptation method)
3) Last but not least, the commands server scripts has to manage all the needed INPUT fields as GET requests. If some fileds are managed only as POST, drupal_http_request parameters needs to be changed.
A patch to configure all the comunication parameters would very useful, even if seems to hard to implement in a flexible way. I'll be glad to work on it if you'll be able to write some working code.
#2
Thanks for your help. With that info and the Mailman link you provided, I was able to work out the correct URLs for GET requests to at least subscribe and unsubscribe.
Proposed solution:
For each UMR function, allow full custom request URLs with token replacement for the password, list-name, parameter values, etc. This would allow the most flexibility and hopefully be the most simple solution to implement. These custom request URLs would override the standardized URLs generated by UMR.
Here are some examples of custom URLs that these configuration options would take:
https://example.com/manage/list/admin/[list-name]/members/add?invite=[invite]&welcome=[welcome]¬ify_owner=[notify-owner]&addrs.addrs_text=[email]&setmemberopts_btn&list_password=[adminpw]&listname=[list-name]&text=[welcome-msg]&auth_types=administrator&menu_hint=general&listauth=true&submit=Submithttps://example.com/manage/list/admin/[list-name]/members/edit/[email]?fullname=[full-name]&hide=[hide]&nomail=[nomail]&metoo=[metoo]&nodupes=[nodupes]&digest=[digest]&plain=[plain-text]unsubscribe=[unsubscribe]&list_password=[adminpw]&listname=[list-name]&auth_types=administrator&menu_hint=general&listauth=true&submit=Submit+ChangesHow does this sound as a solution? A quicker alternative is to forget about the tokens for now and leave it up to the developer to just hand code URLs for subscribe, unsubscribe, digest, etc.
Full documentation would have to come later, but the fields could have some general text to give the basic idea of what the settings are for and some hints about when & how to use them, and an emphasis that they're very advanced settings that are going to be different for every customized Mailman instance and that using the incorrect values could delete the entire list, so the site admin is pretty much on their own for figuring out what to put in the fields.
If it sounds like a solution that you'd put into UMR, I can start working on a patch.
#3
Upon pondering this, I realized that it would be cool if there was a way to define custom calls to
drupal_http_request()- like to be used as Drupal actions or something. It could act as an API for other modules to define their own http request actions, which would then be callable from other modules, could be triggered automatically, etc...Update: Looks like Services (http://drupal.org/project/services) would fit this bill. So maybe down the road UMR could integrate with Services to allow more flexibility in the Mailman calls.
#4
The token replacement solution seems to me the right way, but i have to say that it's not clear to me how Services could help to achive this issue goal.
For what i understand in its description page its main feature is to create a service in Drupal that can be easily used by external client applications, but we need the opposite way. Or do i miss something?
#5
I confused the issue a bit with the Services reference... The thought was not directly related. Many apologies.
#6
The Mailman I'm working with is so modified (or old ;-) that I had to change the response parsing as well, so I made a custom fork of UMR.