Allowing users to Edit their own details with 'SelfEdit'. How does it work?

« 
Previous topic
|
Developer
|
Next topic
 »
Author Message

Stuart Fenton

Saturday 28 June 2003 8:59:06 am

I want to be able to allow users to edit their own User account but even though you have added a SELFEDIT feature to the user module I cannot get it to work. I just get an access denied error. I have added the self edit feature to the role with no effect.

Am I doing something obviously wrong? And is their any documentation on using the feature?

Your help would be greatly appreciated as I have waited over a month now to resolve this issue and I have a backlog of work do do around this feature.

Thanks
Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Paul Forsyth

Sunday 29 June 2003 2:35:12 am

Im working on this too. Try the following roles:

user selfedit *
content edit Class( User ) , Owner( Self )

and finally * * * if all else fails ;) (only for testing of course)

paul

Paul Forsyth

Sunday 29 June 2003 2:38:38 am

read this too:

http://ez.no/developer/ez_publish_3/forum/developer/editing_a_user_profile

http://ez.no/developer/ez_publish_3/forum/developer/publishing_a_user_profile_draft

paul

Stuart Fenton

Sunday 29 June 2003 3:14:20 am

Thanks for the reply. Yes I have read both of those articles but when I replicate your steps they did not work for me hence why I posted the message asking for help.

This is an annoying feature to find answers to because of Ez's approach to their search engine which is to remove words like USER from the search terms making it impossible to search for USER EDIT as it only finds references to edit.

I manually went through every page looking for an answer.

No doubt when it's Monday I will get a reply.

Here's hoping and thanks again for your reply.

Regards
Fats

-- Stuart

[email protected]
http://www.grandmore.com

Paul Forsyth

Sunday 29 June 2003 3:49:56 am

ok. its a thorny problem. btw are you using 3.1?

Does giving the user access to all (* * *) work?

Stuart Fenton

Monday 30 June 2003 2:21:33 am

I think I should give you a quick overview of what I am doing.

Because EZ cannot list content based on user I was going to create a set of objects related under the user account. This keeps the default EZ objects clean from modification to make upgrades easier.

The user signs in, clicks on their account page and instead of displaying their account I display a menu linking to each object. Addresses, credit cards, communication preferences etc. This way if an object does not exist for the user they click the link and it is added under their account. If it does exist it takes them to the override template for the object where they can edit their data.

Because of this method I want to ensure it works before building the pages in case it is wrong.

Back to the issue at hand...

Yes I can edit the details perfectly with full access when logged in as the user in question. I have tried numerous role settings to give them access to their account but it doesn't seem to work.

If you have got it working I would love to know how.

Thanks for you time.

Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Paul Forsyth

Monday 30 June 2003 6:57:42 am

I like where you are taking the user. I haven't tried working with related objects yet in that sense but it sounds like you have a better way of extending the user. Ideally it would be nice for the classes to be naturally more oo-like :)

I created a new shop group with a new shop user with the attributes I needed. With that I also changed the site.ini file to reflect the new ids for the shop user id and group so that new shop users go into the right folder to obtain the right role.

Currently i have following role permissions set for this user and can confirm this works:

content read *
user login *
shop buy *
user selfedit *
content edit Class( User ) , Owner( Self )

The (content read *) is contentious i know but for development and while i add new classes i leave it like this and lock it down later.

Is this any different from your own?

paul

Stuart Fenton

Tuesday 01 July 2003 5:37:29 am

Thanks for the reply,

I replicated your setting and it does indeed work however it only works because the backdoor has been left open :-)

Specifically the "content read *" line is what is causing the solution to present itself but actually I can read every account no matter if it's mine or someone else's.

It is true that I can only edit my own account but I defiantly do not want users accessing other peoples content.

Is their a solution to this quandary I wonder.

I think this is turning into a bug or an undocumented feature.

Does anyone have a working version of this with restrictive role settings in place?

Thanks
Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Paul Forsyth

Tuesday 01 July 2003 6:03:56 am

Well, at least its been narrowed down, and ill hit the same problem sooner rather than later ;)

Im afraid i haven't time at the moment to test narrowing this down. Have you tried narrowing it down yet?

paul

Stuart Fenton

Tuesday 01 July 2003 6:12:54 am

I have done some further playing around and have come to the conclusion that the solution lies in a simple method which I had explored before but I was expecting a resolution in this release.

Basically when the user it created remotely the owner of their account is not themselves but the admin (number 14). This means that the normal roles don't work because the user does not own their own account.

The simple solution would be to alter the ini file to allow "self" to be used in place of the account number. Then the role module could be used with content read Class( User ) , Owner( Self ).

A full setup would then look like:

user login *
user selfedit *
content read Class( User ) , Owner( Self )
content edit Class( User ) , Owner( Self )
content create Class( User ) , Owner( Self )

I will log it as a bug/feature request.

Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Stuart Fenton

Tuesday 01 July 2003 11:20:00 am

I have resolved to do a code modification for the time being. I have trying to avoid doing this but I cannot find another solution. So for the strong at heart here is a modification that will resolve the issue.

I have created a new site.ini variable called UserCreatorIDChangeToUserID I then set this to true if I which to use this feature or false if I do not. This gets tested during registration and if true updates the owner id to make the user object owned by the user.

Origionally I used UserCreatorID and tested it for a zero value. If it was zero then I would execute the code below. However since I don't know is that variable has a meaning when set to zero I added a new variable to keep things separate from any other core vraibles.

Here is the code that needs to be inserted into the register.php file.

If the section that starts with:

if ( $module->isCurrentAction( 'Publish' ) )

Here is the code with the changes in it.

if ( $module->isCurrentAction( 'Publish' ) )
{
$http =& eZHTTPTool::instance();

$user =& eZUser::currentUser();
include_once( 'lib/ezutils/classes/ezoperationhandler.php' );
$operationResult = eZOperationHandler::execute( 'content', 'publish', array( 'object_id' => $object->attribute( 'id' ),
'version' => $version->attribute( 'version') ) );

// Start: Code Modification
// A code change to renumber the owner_id to the object id Modified to ensure that
// users created through registration own their own account. This means that they
// can then edit their own account because they are now the owner of it.

$ini =& eZINI::instance();
$userCreatorID = $ini->variable( "UserSettings", "UserCreatorIDChangeToUserID" );
if ( $userCreatorID )
{
$object = eZContentObject::fetch( $object->attribute( 'id' ) );

$object->setAttribute( 'owner_id', $object->attribute( 'id' ) );
$object->store();
eZDebug::writeWarning( "Content Owner ID changed to:", $object->attribute( 'owner_id' ) );
}
// END: Code Modification

And don't forget to put the new variable in the site.ini file.

This is hopefully only a temporary solution because I don't really like changing the base code it goes against my laziness as I will have to bear this in mind evcerytime I do an update.

Anyway hope it helps, it has for me.

Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Paul Forsyth

Tuesday 01 July 2003 11:51:34 pm

thanks!

but, shouldn't the code be

*snip*
$object->setAttribute( 'owner_id', $userCreatorID);
*snip*

paul

Stuart Fenton

Wednesday 02 July 2003 12:02:23 am

If that variable is dancing around at the moment publish is started then sure, It would be faster.

Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Paul Forsyth

Wednesday 02 July 2003 1:46:49 am

No, i meant that it looks to me your code has a typo in it.

paul

Esben Maaløe

Tuesday 29 July 2003 8:03:52 pm

I've tried Fats' hack - I didn't bother with the inifile stuff - 'cause I want my users to be able to change their email adress all the time.

No - Paul that isn't a typo - userCreatorID is set to the value in the *.ini file - the owner can't be true or false :)

I've set up policies thusly:

user login *
user selfedit *
content read Class( User ) , Owner( Self )
content edit Class( User ) , Owner( Self )
content create Class( User )

The new users are able to get all the way to the 'edit' screen - but they can't publish ! When they try they get access denied :(

Fats - u have an idea on this ?

Selmah Maxim

Wednesday 30 July 2003 12:46:52 am

in site.ini under [RoleSettings] you need to add
PolicyOmitList[]=user/edit

Esben Maaløe

Wednesday 30 July 2003 8:37:11 am

Allowing user/edit by omitting the check sounds like a user would be able to edit any user by Changing SITEURL/content/edit/OWN_ID to SITEURL/content/edit/ID_OF_ANOTHER_USER ?

You should check that Selma - it may be a hole in your setup....

Well - I believe Fats is spot on. It is definately a problem with ownership - and changing the ownership of the new user account to it's own id is the cure...

I tried to change the content owner back and forth directly in the Database - and it is def. an owner problem.

What further foiled me was that I (as the new user) got redirected back to the 'view group' page to which I had no read access !!!

But instead of getting a message saying 'Your changes are stored - but you can't view this page' I got 'Access Denied' which I wrongly interpreted as 'Access denied - you can't change anything'

So now I allow the usergroup to be viewed - I plan to extend the user class with options to show or not show things like email etc...

These are the permissions I've found to be essential for it to work (NB: Together with Fats hack):

content read Class( User group , User ) , Section( Users )
user login *
content edit Class( User ) , Section( Users ) , Owner( Self )

Stuart Fenton

Friday 01 August 2003 1:52:31 am

The code should work correctly as I've tested it extensively.

Selma, you could set the role in the way your suggesting but it means that a different user could edit the account instead of the one that created it. Changing the owner is the only was to achieve self editing and still maintain strong security.

This way EZ correctly identifies the owner when a user tries to access another's account and stops them from doing so.

Fats.

-- Stuart

[email protected]
http://www.grandmore.com

Robin de Silva Jayasinghe

Wednesday 18 August 2004 1:56:28 pm

in case you want to create your users via the textlogin-handler. you should add the following to eztextfileuser.php in /kernel/classes/datatypes/ezuser :

$object->setAttribute( 'owner_id', $userID);

It should be added in the column where the new user-object is created.

visit http://www.jayasinghe.de
Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.