password is set to username

I just installed this module and had this happen too, although I did find out why it happened.

When a user account already exists, and an email account is created, a password has to be entered into the passwords fields in order for this module to work properly. Otherwise, it defaults to the username, spaces and all.

There needs to be some error checking to verify that a password is valid, and if not, give the user a chance to enter a valid password.

IN all honesty this has stopped me using this module as its a big security risk.

Its a shame as most of the work is there. All it needs is a password box in the user panel and we are pretty much done. Having the password set to the username is a huge no no.

Has this been addressed yet ?

I still see this as a MAJOR security risk for SPAM emails.

Yes, working is on progress. Next week I will release a major update of this module for 4.7.x , including:

- No more info stored in user profile. Now all data will be places on SQL tables. This solve most issues regarding to warnings and other stuff
- Create/delete of accounts now are fired by cron
- Added support for forwarders
- Fast link for users to download registry files to auto-configure clients like Outlook, Outlook Express and Thunderbird
- Admin can hide Cpanel item on users profile
- Permissions by role to: create accounts, delete own accounts

Keep in touch

Sounds fantastic and its nice to see it developed again but what about mail account password ?

I just can't use this module till that's addressed. Using the members registered name as the password is opening all sorts of issues.

Is that to be addressed ? Maybe using their drupal password or better still, asking them on signup for a password ?

Main problem is that user passwords are stored crypted with MD5, and that can't be reversed. So, to use the same password, we need to wait until user change it from its account panel.

Previous solution was assign its username as password. (Bad, of course)

This is how it works now:

1. All creation/deletion requests goes to a queue (table). If an user just request for an account without change his/her password, a record is created on cpanel_email table and marked as "Requested". Cron will no take action.
2. When the password is changed, it is stored temporarily (max. one hour) in the table. Once cron runs, creation of accounts happen. After that, password is removed from table, and record is marked as "Created".

I'm not quite following this in its present state.

When a user requests an account it goes in a cron to be modified by the admin for a password to be assigned ?

I think, in honesty, the best method to rectify the issues with passwords is assign the module two password boxes on request of an email account. The first is the password the user wants for his.her account, the second checks the first. Give them the option to change that at any time as well and you have a system that is flexible and easily maintained by the user. Its instant without any need for moderation.

This means their password is separate from their drupal login (always a good idea for security purposes anyway) and is fully under their control.

Coupled with your ideas for downloading an outlook express file that should do it nicely.

Obviously there should be some access controls to this to set rules to who can create email accounts (i.e. only validated registered members etc).

Maybe I didn't explain me as good as I think.

Cron runs without admin intervention, so accounts are created automatically every hour.

About the passwords: Main idea about this module was get synced drupal accounts with email accounts. Let users choose another password for email accounts is not on my mind, and can bring a confuse profile page for users when edit their accounts. In a standard profile page already are two fields to input and confirm the password.

This is how profile looks:

Personally i disagree here. You'll confuse people more when they don't know their current email password, download an outlook express file, import, change their drupal password at a latter date and then wonder why on earth their email address has now stopped functioning.

Personally i truly thinking that this module should move its settings to a sub page of the user profile under something like "create an email account" and then you take away the confusion completely.

You can have the password boxes set up there and more indepth explanations of how, what and where their email address and / or ftp will be usable. If they want to change their email password at any time, they visit that page, change it with the boxes and redownload a new outlook express file. Simple and clean.

I'm not convinced that your approach is user friendly i'm afraid and still see it as a major hookup that you can't set a password without changing your drupal password at the offset. After all they are two seperate commodities and members will be using emails away from your drupal install anyway so really can't see the need to keep them the same.

However i'm not developing the module so basically thats your call. All i can do is highlight the potential for the module and hope you'll take them into consideration.

Sure. Your feedback is really appreciated. Maybe I can give both options to admins.

Now that would be perfect :)

I'm with yecarrillo on this. I will want my users to either automatically get a drupalUsername@mydomain.com email address on sign up to a specified level or upon request. Keeping the password the same is a good idea in my opinion, as the user can easily get a password reminder through existing facilities when they forget it (which they will). I will of course be waiting for the first user to set their drupal email address to the one created by cPanel - password reminders will be tricky then... ;-) Perhaps there could be a check to make sure this cannot happen? Not allowing the drupal email address to be anything at domainName.com would probably do it.

Personally, I would also love to see a tighter integration between cPanel and Pontomail, and in particular to have cPanel automatically populate the pontomail database with the details for the new account. This would probably be quite simple? Of course, a change of email address would mean updating of the mail account password AND updating of the relevant pontomail record.

cPanel really is excellent work though :-)

Oh, and with regard to the original issue of a password being required, why not simply have a field that request password confirmation? Yecarrillo, you stated:

"Main problem is that user passwords are stored crypted with MD5, and that can't be reversed. So, to use the same password, we need to wait until user change it from its account panel."

If the user enters their password upon creation of an account then it can be checked against the encrypted password in the database (MD5 sum or something like that if I remember correctly from a few years ago).

It's getting late, so I could be typing nonsense, but.... user registers and they are sent an email with a password (for my setup)... user goes to site to authenticate and will then possibly change their password. Does this impact upon the complexity of automatic email creation when someone signs up?

Edit for post 12 - in the last sentence of my second paragraph I meant a change of password and NOT a change of email address...

I still disagree here.

For one you are forcing an existing user to change their password to sync the drupal and email passwords. If you don't do this then their password is set to their username which is both a security issue and a confusion.

Ad to that there now in a cron job and their accounts don't get automatically created as they have no password set and there you'll have people saying "erm i can't get my email to work ? and i have no clue what my password is ?."

Its just the opinion i have and personally won't use the module without a foolproof way for my members to automatically, without admin intervention, create their own email account. After all i could log into cpanel and do it manually if that is going to be required.

It would be perfectly fine for new users signing up to adopt the approach the module is taking but for already existing members i feel your causing confusion and admin work for, frankly, no reason at all.

What you could do is have a checkbox on signup "do you wish to have username@yourhost.com" and set both password to be the same and then a sub panel to allow you to change the email password at a latter date (those allowing for already registered members to automatically set their password).

This all sounds negative and its really not meant to be. I actually made the original request for this module and was overjoyed when it was created. But i haven't been able to use it due to the way it implements passwords. I know my users and know that they will have confusion on the way it currently operates.

I do wish to thank the module author for an outstanding work and i truly wish i could use it :( But if thats the approach it will take then i'll personally leave it at that as i think its just confusing (its confusing me and i have to explain it to my members).

Personally i still feel a sub panel with password settings fits all. But as i've said before i'm not capable or authoring the module so this is just my personal opinion.

I'll keep an eye on it, hope that these issues are addressed and wish the module author well.

I'm not entirely sure why there should need to be a different password for the email, but I also do not see why this cannot easily be implemented as suggested. A password reminder facility would also obviously need to be included for the email. Again, it would be useful if this updated the pontomail database as well. I agree that it should not be possible for the username to be set as the password, but that should easily be dealt with. However it ends up working, as long as the username cannot be set as the password, all is good!

I agree there is no need for a seperate password but this is where the troubles lay. Drupals password is encrypted so the author of the module cannot inject that into cpanel. To this end existing members are forced to update their sitewide password just to gain a new email address and this is where i feel the confusion will play its hand.

If it could be done that their sitewide password is used automatically when they check the box requesting an email account then great, but i don't think thats possible. Requesting an email and then the admin having to manually add it or force the member to change his sitewide password misses the entire point of the module being automatic and under the control of the member to request his own email account.

So your then left with either the setting of a new sitewide password, setting a temporary password, using their username as a password (a big no no) or as i see it, seperating the process completely and letting it be under the control of the member. Let them set their own password for their email address, provide a downloadable outlook express file and all is good.

And you wouldn't need a password reminder for their email account as if they couldn't recall it it wouldn't lock them out of the website. So they simply come in, change their email password to one they can remember, their account gets updated and away they go. Simple and easy.

By trying to make things as uncluttered as possible you bring in confusion. Separate the process, explain to the member every step of what they are doing and you decrease the potential for issues later on.

I still think a separate panel, with password boxes for the email account is the best solution to the problem.

I think if your starting out then it may not be a big issue as new signups could use set password for both accounts. However in a live system, where members already have their password intact, your running against the wind.

When I tested this I ticked the box for an email account and entered my existing drupal password, so it is not the case that the user has to choose a new password. I still see your point though.

Existing users could be asked to verify their drupal password when requesting an email address. Enter password, md5 validation check, if true then the entered password can have been made available for cPanel to set up the email account with that password. No password entered would not validate, therefore avoiding the problem of accounts being set up with the username as a password. If the user updates their drupal password AND they already have an email account ... probably update email account password at that time as well? This would all keep email and drupal passwords synchronised, if indeed this is still seen to be a good idea, which I think it is.

As for changing passwords, I still think it is odd that you can simply enter a new password without having to also confirm the current password. A large number of sites require entering the current password and desired new password, thus ensuring that passwords can only be changed by the member.

"username as a password" problem has been solved a few moths, please stop talking about that. I plan to make public the new version to make test and make concrete changes.

That would explain why it didn't happen when I tried it then... ;-) Looking forward to seeing what you come up with.

When I tested this I ticked the box for an email account and entered my
existing drupal password, so it is not the case that the user has to
choose a new password. I still see your point though.

Well again this is valid really isn't it. Your asking the user to set a password anyway so why on earth the need for the same password as Drupal ? Why does it have to use the same password boxes ? And why, taking the process to a seperare sub page, can this not be how the module works at the start ?

After all if it was on a seperate sub page couldn't the user simply set the password to the same one as his/her drupal account if that user needed or wanted ?

Again i'm totally confused on the need to keep this synced with a drupal password when in reality its not drupal in question but an offsite service your running that drupal is helping you automate.

You highlighted the point here straight away that its not a one click event as it stands. You have to click the request email account and THEN set a password again.

I guess we'll see how this is addressed if at all but if it stays the way it is i feel the module is missing its full potential. But as i've said many times i am not developing it and the author has every right to go in the direction he see's fit. I do appreciate his efforts and all i'm trying to highlight is from a user level the way its heading isn't, in my mind at least, the best possible method for your average website user. I hope that comes across more than me being negative as it simply isn't my intent.

It has been almost a year and no fix has been made public or posted as far as I can tell. I would like to solve this issue.