User should not be able to change password User should not be able to change password
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

User should not be able to change password

Started by prime1, February 27, 2007, 09:55:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

prime1

Hi all

New here, have been lurking a bit but it's my first post, so I'm hoping that I'm posting in the correct forum.

I love Coppermine, used it for a friend of mine. Now I want to use it for myself as some sort of catalogue.

The question is: can I prevent a user from changing his password?

Meaning: I want to send out a username and password myself, and the user shouldn't be able to change that password because I'm only going to use one user account for specific persons (they 'share' that account).

Is this possible?

Thx heaps!!

Prime1

Joachim Müller

Shared accounts for several people is a very bad idea (veeery baaad - I mean it). I strongly suggest reviewing it. You could use the option "Allow users to change their email address in profile" in Coppermine's config though - read the documentation first please!

prime1

Thx for the reply.

Let me elaborate on this. The user will not be able to upload/change/... anything, only view things. That is why a shared account is actually very practical in this case.

They do need to log in before they can view anything at all.

However, I don't want a user to be able to change his/her password, that is a thing that I only (as admin) should be doing. That way I can send out username and password myself to chosen people that are allowed to view galleries, others that can view other galleries and so on.

The email setting isn't the problem (and I did read all the documentation!), the thing is that I want to prevent a user from changing the password.

Is there a way of doing this? When a user from one particular group logs in, they aren't allowed to change password?

Thx again

Prime1

Tranz

An alternative is to set album passwords:

QuoteAlbum Password: you can specify an album to be password-protected (instead of relying on the "regular" group-based permissions). This way, you can even allow access for unlogged users (guests) who you provide the password to. Use this option, for example, to set up an album for your family members only by specifying a password that only they can come up with answering an additional password hint (e.g. "What was the maiden name of aunt Emma?"), or you could decide to send the particular password to specific friends, family or business associates by email. The optional password hint will be displayed at the password prompt, when set.

Note: when setting an album password, the permission dropdown field "Album can be viewed by" will be switched automatically to "me only" - this is expected behaviour. If you change the "Album can be viewed by" to another selection, you must disable the album password as well.

prime1

Hi again

I already tried that one, but it really doesn't suit my needs I'm afraid.

I don't want to be a pain, but is there a way to prevent a user to change his/her password?

Thx

Prime1

Joachim Müller

Edit profile.php, find<input type="submit" name="change_password" value="$title" class="button" />and replace with<!--<input type="submit" name="change_password" value="$title" class="button" />-->.

However (as I suggested already): I consider this a bad approach in the first place. Review the idea to share one login for many users. Really!

prime1

Thx heaps!!

Didn't even think about commenting it out, me feeling quite stupid now  ::)
I also commented this out to have it so that people don't get to the input fields.

<!--<input type="submit" name="change_profile" value="{$lang_register_php['apply_modif']}" class="button" />-->
            <!--<img src="images/spacer.gif" width="20" height="1" border="0" alt="" />-->
            <!--<input type="submit" name="change_pass" value="{$lang_register_php['change_pass']}" class="button" />-->


Question if I may: is this a safe way of doing this or is it just a purely "visible / invisible on screen" solution?

And yes, I can totally understand that you don't like this way of doing things, it is just quite practical in my case.

Thx again

Prime1

Nibbler

It's only affecting the interface. If you want to make it secure you'd need to play with the actual php.

Joachim Müller

You're afraid about the security impact this will have, yet you're about to let several people share one login? LMAO... Making several people share one login is not secure in the first place.

prime1

Nibbler, thx. Will do some further digging then.

@GauGau
QuoteYou're afraid about the security impact this will have, yet you're about to let several people share one login? LMAO...
Euhm, funny is it? Euhm, respect to others? ...

The account can't do a thing, that is just it. Consider them all as guests, but who have to log in, that's all there is to it. But, guests that can't change their password.

And, it was a simple and polite question I believe, definately not a reason to get personal.

Schnaaf

Within profile.php find:

        starttable(-1, $title, 2);
make_form($edit_profile_form_param, $form_data);
        echo <<<EOT
    <tr>
        <td colspan="2" align="center" class="tablef">
            <input type="submit" name="change_profile" value="{$lang_register_php['apply_modif']}" class="button" />
            <img src="images/spacer.gif" width="20" height="1" border="0" alt="" />
            <input type="submit" name="change_pass" value="{$lang_register_php['change_pass']}" class="button" />
        </td>
    </tr>
EOT;


And replace with:

        starttable(-1, $title, 2);
make_form($edit_profile_form_param, $form_data);
if ($user_data['group_name'] != 'Guests') {
        echo <<<EOT
    <tr>
        <td colspan="2" align="center" class="tablef">
            <input type="submit" name="change_profile" value="{$lang_register_php['apply_modif']}" class="button" />
            <img src="images/spacer.gif" width="20" height="1" border="0" alt="" />
            <input type="submit" name="change_pass" value="{$lang_register_php['change_pass']}" class="button" />
        </td>
    </tr>
EOT;
}


Now all users within group 'Guests' cannot change their profile via the form.

Tom

Joachim Müller

@Schnaaf: thanks for posting. I understand that you're trying to be helpful. However, I have some remarks to make:
Quote from: Schnaaf on May 22, 2007, 08:31:40 PM
Now all users within group 'Guests' cannot change their profile via the form.
That's not what the thread starter requested: the single generic user that his visitors are suppossed to use won't be member of the "guests" group, but a member of the "registered" group. Guests (i.e. non-logged in visitors) won't be able to edit their profile anyway, since they don't have one. Try for yourself on your gallery: log out (you'll be a guest then), then point your browser to http://yoursite.tld/your_coppermine_folder/profile.php?op=edit_profile
You'll get an access denied error message.

Anyway, your changes to the form won't do anything in terms of security; the previously mentioned hacks will cripple the form as well. This will not harden the PHP code the form is being submit to.

Schnaaf

@Gaugau:
A user will be member of a group the admin assigned him to. Agree?

If the admin assigns him to be a member of group "registered" - so be it. If the admin choses to assign him to group "guests" - that's possible as well.

This quick hack will do the following: It presents an edit profile form to the casual gallery visitor (who is not familiar with the details of coppermine php code and  a member of group <guests>) that does not contain buttons to change password or email address - that's all - nothing more nothing less.

In case the user is experienced with the coppermine php code - yes he could still change his password by submitting a POST request to profile.php.

Best regards,
Tom




Joachim Müller

The registered group and the guest group are generic. You can't assign users to them. Visitors who have an account will be members of the regietered group. People who have no account will be members of the guest group. You mustn't force users who have an account to be members of the guests group.
If a user is member of several groups, least restrictive permissions apply.
Your hack could only work if you assign the special user the thread starter talked about to be member of a particular custom group (maybe name the group "special") and change your hack accordingly. However, the group in question would only have one member (as the thread starter planned to have only one registered user and use that user for several people), so it would be even easier if the hack just checked for a particular user ID.

As I suggested: the hack that you have come up with just cripples the form. The script that the form data are being submit to doesn't get changed. Users who know their way around could send made-up form data to that script and subsequently perform profile changes.

Anyway, imo this thread has been abandoned by the original thread starter anyway, so this discussion is very theoretical. I'm only posting this to clarify to others who might come across this thread later that the original idea the thread starter has come up with is not a bright idea and that the hacks posted here to circumvent things are not proof against hacking.