MVC Relate Site - save page errors

Vote:
 

Hi,

I have a 7.5 Relate site which is also MVC. One of the requirements is to have a read only use profile page and the Relate user object needs to have additional custom properties which have been added in Community admin mode, an example is ExternalUserID (string) and there are a few others.

On the page type I have a property of IUser which is decorated as [Ignore] as it's not editable in EPiServer as follows

[Ignore]
public virtual IUser ProfileUser { get; set; }

I also have a corresponding property for each addtional custom attributes I added to the Relate user object - so that my view is less cluttered i.e. so that I don't have to check the attribute is null etc in the view. For example:

[Ignore]
public virtual string ExternalUserID
{
   get { return "check for null etc, return string"; }
}

Now this works in that the page loads and the fields are displayed as expected however I am encountering errors when editing and trying to save the page.

Firstly I get the error:
Property accessor 'ExternalUserID' on object 'Castle.Proxies.UserProfilePageProxy' threw the following exception: 'Object reference not set to an instance of an object.' Object reference not set to an instance of an object.

If I change ExternalUserID to:

public virtual string ExternalUserID()
{
   return "check for null etc, return string";
}

This prevents the previous error, but somehow doesn't cause errors with the other custom attributes, but I get the error:

Property accessor 'Password' on object 'EPiServer.Common.Security.User' threw the following exception: 'Cannot decrypt password.' Cannot decrypt password.

For the first error I'm not trying to set the ExternalUserID for the second I'm not trying to do anything with the password.

Any suggestions?

Thanks,
Mark

#88188
Jul 04, 2014 11:44
Vote:
 

Does anyone have any thoughts on this at all?

#88239
Jul 07, 2014 17:25
Vote:
 

Hi

Not answering your issue but you have potential issue with the ProfileUser property if it is used like shown in your sample code. Remember that the page instance is cached and that ProfileUser property is then "shared" like a static property by the whole application. I mean that if you have some code that gets the page from repository and in the controller you set the ProfileUser this works fine as long there is only one user if there are more concurrent users you will most likely end up having the wrong IUser in the ProfileUser property.

Test it in debugger for example with 2 separate browsers (private mode) and make request to your "read only" profile page. Where ever you populate the property after the first request brake the execution and make another request from another browser and let that execute and now see the ProfileUser property in the halted execution flow. It should be the second requests profile (so do have 2 separate profiles for the requests) or another way to test this is that when the second request is made you can see that the ProfileUser property is already set.

#88481
Jul 15, 2014 9:32
Vote:
 

^-- so what I tried to say is that the IgnoreAttribue is EVIL! And is safe only when the property should be shared or is not backed by a field (has code that changes the return value based on something).

#88482
Edited, Jul 15, 2014 9:33
Vote:
 

If it helps anyone I removed the IUser from the page type and in the controller I get the relevant user object and set each property that I need.

#88624
Jul 21, 2014 11:24
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.