Confusing personalize security-constraint behavior

[knovoselov]

Confusing personalize security-constraint behavior

Hi,

I am playing with personalize permissions in Portal 2.4 CR2. I granted personalizerecursive permission to Admin for News page in Portal Admin and verified that portal does not have personalizerecursive set.

Admin user personalizes portlets just fine and I see his entries in JBP_PORTLET_STATE table. So far so good. Now unauthenticated user still able to personalize and see new content. No changes in database are made and preferences revert to default at some point, i.e. after I login and logout.

It?s even more interesting for user/user. I can personalize Wheather portlet and see the settings in JBP_PORTLET_STATE_ENTRY_VALUE. After logout/login I see default zip code. Changed zip code again ? the record in JBP_PORTLET_STATE_ENTRY_VALUE is gone. Weird.

Is it a bug or a feature? I really don?t like idea explaining my customers why I lost their changes. I think it would be much better to hide Edit icon if user does not have personalize permissions and display some ?security violation? error if user gets to edit mode using direct URL.


Thanks,
Konstantin Novoselov

[julien1]

that is fixed in the current 2.4 head cvs, and we will release CR3 soon (actually it is tagged in cvs).

[knovoselov]

Hi Julien,

I installed CR3. The personalize behavior is the same for not authenticated requests.
Authenticated user can personalize portlets without having "personalize" permission. Changes persisted to DB and used for next login session.

So I beleive it is still broken.

Thanks,
Konstantin Novoselov