|
From: Bill M. <bm...@ud...> - 2008-01-23 22:19:06
|
Hello, we are looking to allow anonymous account activation for mailbox users. In other words, creating a mailbox user would send mail to the person's alternate address containing an activation url where they would choose a password. This is to avoid having to send a placeholder password over email. I could not find an existing module to do this in virtualmin. Does anyone know if such a module exists? |
|
From: Jamie C. <jca...@we...> - 2008-01-23 22:30:58
|
On 23/Jan/2008 14:18 Bill Moyers wrote .. > Hello, we are looking to allow anonymous account activation for mailbox > users. In other words, creating a mailbox user would send mail to the > person's alternate address containing an activation url where they would > choose a password. This is to avoid having to send a placeholder password > over email. I could not find an existing module to do this in virtualmin. > Does anyone know if such a module exists? There is no module like this currently, but there is one that allows users to sign up for mailboxes (and pick passwords) without needing a Webmin login. See : http://www.webmin.com/cgi-bin/search_third.cgi?search=mailbox+signup Not exactly the same, but similar .. - Jamie |
|
From: Bill M. <bm...@ud...> - 2008-01-29 18:39:25
|
Hi, I have been working on a module to do as described below. I am using
the webmin passwd module method passwd::change_password to do the actual
password change. I think I found either a bug or something that could use
clarification. It seems that if you don't use the passwd::find_user method
to get the user hash that is an argument to change_password it behaves
unexpectedly.
For example, on our system if you try to change an ldap user's password it
will fail to check ldap-useradmin for the user and default to useradmin
(i.e. writing to /etc/shadow). I guess since it doesn't find the user it
silently over-writes the first row of /etc/shadow which is often root.
This happened in testing a few times and is obviously not good.
I think the reason is that find_user sets $user->{'mod'} whereas it looks
like other components use $user->{'module'} to set which module the user
is in. When I change that it works using user hashes from other functions.
I don't know if this is considered a bug, but you might want to give a
warning in the passwd module code so future module writers don't have all
kinds of errors in their /etc/shadow.
> On 23/Jan/2008 14:18 Bill Moyers wrote ..
>> Hello, we are looking to allow anonymous account activation for mailbox
>> users. In other words, creating a mailbox user would send mail to the
>> person's alternate address containing an activation url where they would
>> choose a password. This is to avoid having to send a placeholder
>> password
>> over email. I could not find an existing module to do this in
>> virtualmin.
>> Does anyone know if such a module exists?
>
> There is no module like this currently, but there is one that allows users
> to sign up for mailboxes (and pick passwords) without needing a Webmin
> login.
> See : http://www.webmin.com/cgi-bin/search_third.cgi?search=mailbox+signup
>
> Not exactly the same, but similar ..
>
> - Jamie
>
|
|
From: Jamie C. <jca...@we...> - 2008-01-29 18:48:44
|
Hi Bill,
Thanks for pointing this out - I will add additional validation
in the useradmin::modify_user function to prevent invalid user objects
like this from causing incorrect lines to be deleted.
- Jamie
On 29/Jan/2008 10:39 Bill Moyers wrote ..
> Hi, I have been working on a module to do as described below. I am using
> the webmin passwd module method passwd::change_password to do the actual
> password change. I think I found either a bug or something that could use
> clarification. It seems that if you don't use the passwd::find_user method
> to get the user hash that is an argument to change_password it behaves
> unexpectedly.
>
> For example, on our system if you try to change an ldap user's password it
> will fail to check ldap-useradmin for the user and default to useradmin
> (i.e. writing to /etc/shadow). I guess since it doesn't find the user it
> silently over-writes the first row of /etc/shadow which is often root.
> This happened in testing a few times and is obviously not good.
>
> I think the reason is that find_user sets $user->{'mod'} whereas it looks
> like other components use $user->{'module'} to set which module the user
> is in. When I change that it works using user hashes from other functions.
> I don't know if this is considered a bug, but you might want to give a
> warning in the passwd module code so future module writers don't have all
> kinds of errors in their /etc/shadow.
>
> > On 23/Jan/2008 14:18 Bill Moyers wrote ..
> >> Hello, we are looking to allow anonymous account activation for mailbox
> >> users. In other words, creating a mailbox user would send mail to the
> >> person's alternate address containing an activation url where they would
> >> choose a password. This is to avoid having to send a placeholder
> >> password
> >> over email. I could not find an existing module to do this in
> >> virtualmin.
> >> Does anyone know if such a module exists?
> >
> > There is no module like this currently, but there is one that allows users
> > to sign up for mailboxes (and pick passwords) without needing a Webmin
> > login.
> > See : http://www.webmin.com/cgi-bin/search_third.cgi?search=mailbox+signup
> >
> > Not exactly the same, but similar ..
> >
> > - Jamie
> >
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> -
> Forwarded by the Webmin development list at web...@we...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-devel
|
|
From: Bill M. <bm...@ud...> - 2008-02-06 15:58:51
|
Hi all, I have written a module to allow anonymous account activation or
password recovery (generalizing it to Anonymous Password Change (APC)).
The module generates a uuid and then allows anonymous access through that
uuid to change account passwords. I want to submit it, but unfortunately I
had to make some changes outside the module (i.e.
virtual-server-lib-funcs.pl) to make it go.
We wanted the choice of using the module to be on a per user creation
basis, so I had to add a checkbox to edit_user.cgi that sets a flag in the
user hash. I also added some lines in create_user (in
virtual-server-lib-func.pl) to check for the flag and call the module
library to create a uuid. Then it adds the uuid to the hash. I also had to
change send_template_email to check for the uuid in the hash and set a
variable ${APCLINK} in the outgoing template email.
Does anyone have any ideas on how to separate this from virtualmin so it
can just be a plugin? Although the code I wrote checks for the existence
of the plugin so it could technically be distributed I doubt that it would
warrant being incorporated in the virtualmin 'core'.
|
|
From: Jamie C. <jca...@we...> - 2008-02-06 18:14:36
|
Hi Bill, If you are implementing this as Virtualmin plugin (with a virtual_feature.pl file), you can have your own input fields added to the mailbox user form by defining the mailbox_inputs function in virtual_feature.pl . This is the recommended method, as it removes the need to modify the core Virtualmin code, and so will continue to work even after an upgrade. For details on writing plugins, go to http://www.virtualmin.com/documentation/ and then to the plugin developer's documentation. - Jamie On 06/Feb/2008 07:58 Bill Moyers wrote .. > Hi all, I have written a module to allow anonymous account activation or > password recovery (generalizing it to Anonymous Password Change (APC)). > The module generates a uuid and then allows anonymous access through that > uuid to change account passwords. I want to submit it, but unfortunately I > had to make some changes outside the module (i.e. > virtual-server-lib-funcs.pl) to make it go. > > We wanted the choice of using the module to be on a per user creation > basis, so I had to add a checkbox to edit_user.cgi that sets a flag in the > user hash. I also added some lines in create_user (in > virtual-server-lib-func.pl) to check for the flag and call the module > library to create a uuid. Then it adds the uuid to the hash. I also had to > change send_template_email to check for the uuid in the hash and set a > variable ${APCLINK} in the outgoing template email. > > Does anyone have any ideas on how to separate this from virtualmin so it > can just be a plugin? Although the code I wrote checks for the existence > of the plugin so it could technically be distributed I doubt that it would > warrant being incorporated in the virtualmin 'core'. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > - > Forwarded by the Webmin development list at web...@we... > To remove yourself from this list, go to > http://lists.sourceforge.net/lists/listinfo/webadmin-devel |
|
From: Bill M. <bm...@ud...> - 2008-02-07 14:01:25
|
> If you are implementing this as Virtualmin plugin (with a > virtual_feature.pl file), you can have your own input fields added to the > mailbox user form by defining the mailbox_inputs function in > virtual_feature.pl . This is the recommended method, as it removes the > need to modify the core Virtualmin code, and so will continue to work even > after an upgrade. > > For details on writing plugins, go to > http://www.virtualmin.com/documentation/ and then to the plugin > developer's documentation. Jamie, you're right. I didn't know about the mailbox_inputs function in the docs. Thanks, that solves that problem. Also, we'd like to inject into the user creation email a variable containing a link to the activation page. Looking through the docs and the source, I don't see any way that plugins can change the substitution hash for template emails. If such a thing doesn't exist, maybe there could be another function in the virtual_feature.pl api such as mailbox_email_substitutions which returns a hash of additional email substitution variables and is called by send_template_email. I can see how potentially other plugins might want to be able to do this as well, but you might not agree that it's important enough to warrant changing the core. The only solution I can see without such a function is to have mailbox_save actually insert the link directly into the template email, but that's bad because there's no (I think) guarantee that the save will be called before the email is sent, and it's just an ugly solution. |
|
From: Jamie C. <jca...@we...> - 2008-02-08 02:13:57
|
On 07/Feb/2008 06:00 Bill Moyers wrote .. > > If you are implementing this as Virtualmin plugin (with a > > virtual_feature.pl file), you can have your own input fields added to the > > mailbox user form by defining the mailbox_inputs function in > > virtual_feature.pl . This is the recommended method, as it removes the > > need to modify the core Virtualmin code, and so will continue to work even > > after an upgrade. > > > > For details on writing plugins, go to > > http://www.virtualmin.com/documentation/ and then to the plugin > > developer's documentation. > > Jamie, you're right. I didn't know about the mailbox_inputs function in > the docs. Thanks, that solves that problem. > > Also, we'd like to inject into the user creation email a variable > containing a link to the activation page. Looking through the docs and the > source, I don't see any way that plugins can change the substitution hash > for template emails. > > If such a thing doesn't exist, maybe there could be another function in > the virtual_feature.pl api such as mailbox_email_substitutions which > returns a hash of additional email substitution variables and is called by > send_template_email. I can see how potentially other plugins might want to > be able to do this as well, but you might not agree that it's important > enough to warrant changing the core. > > The only solution I can see without such a function is to have > mailbox_save actually insert the link directly into the template email, > but that's bad because there's no (I think) guarantee that the save will > be called before the email is sent, and it's just an ugly solution. There is actually a slightly hackish way you could do this - in the mailbox_save function, you could set a key of your own in the user hash parameter (the 1st) with code like : $_[0]->{myplugin_something} = "whatever"; Then in the email template, you can refer to ${MYPLUGIN_SOMETHING} which will be replaced with whatever you set. - Jamie |