Ticket #756 (closed Task: fixed)

Opened 6 years ago

Last modified 6 years ago

Observations on recent nightly

Reported by: JuergeN Owned by: jri
Priority: Major Milestone: Release 4.5
Component: DeepaMehta Standard Distribution Version: 4.5
Keywords: Cc:
Complexity: 3 Area:
Module:

Description

Hey, I know things are not ready yet, but as I do not want to forget about it, I out my recent observations of the status quo here:

  1. Create New User

Any user can create another user (in their private workspace). From workspace ACL logic this is clear, because the user has read permission on the type and write permission in their private workspace. The question is: do we want this?

My opinion: NO - I think that only users with write permission on the system workspace should be able to create new users, unless we have a self-register plugin installed or we think it is really charming that anyone can create new users. ;-)

  1. Search

I do net yet fully understand the impact of our workspace ACL to the search. It seams that a search|~result is stored in the workspace where I search. What does that mean, if I do not have write permission on a workspace? In the very logic of our workspace ACL it would mean that I need to be in a workspace where I have write permissions, to be able to place a search. I think this is very logical, but it also means, that people who are not logged into the system in any way, cannot do a search, unless the system allows for annonymous editing. Am I right?

Change History

comment:1 in reply to: ↑ description Changed 6 years ago by jri

Replying to JuergeN:

  1. Create New User

[...] I think that only users with write permission on the system workspace should be able to create new users ...

Yes, we already agreed on that (on the phone I think).
This will be implemented very soon.

  1. Search

I do net yet fully understand the impact of our workspace ACL to the search. It seams that a search|~result is stored in the workspace where I search. What does that mean, if I do not have write permission on a workspace? In the very logic of our workspace ACL it would mean that I need to be in a workspace where I have write permissions, to be able to place a search. I think this is very logical, but it also means, that people who are not logged into the system in any way, cannot do a search, unless the system allows for annonymous editing. Am I right?

Yes, indeed, search is a special case.

From the design perspective I would pursue the behavior that is realized now: a user can search/find any content where she has READ permission to, regardless whether the selected workspace is WRITEable or not. (See also the hint below). Otherwise the case for search would be too limited.

One could argue that way: traditionally search/retrieve is a read operation, that is GET semantics. It is only a DM specialty that things are created while a search (namely the Search topic and Search Result Item associations), that is POST semantics. So, currently we interpret a DM search in the "traditional" sense, not strictly technically.

Already with DM 4.4 and before search is treated special in this very regard. By default a user who is not logged in is not allowed to issue POST requests at all. We worked around that by triggering a search via a GET request (instead POST what would be adequate).

Currently with 4.5-SNAPSHOT search is functional only because access control for create operations is not yet strictly enforced at the backend. Once it is, I think we need to implement an exceptional rule to widen the permission for a "create search topic" operation, in order to keep the behavior as it is now.

One general (not 4.5 specific) hint about permissions and topicmaps: a user who has no WRITE permission to a topicmap is still free to manipulate the topicmap in any possible regard (e.g. move things, hide/reveal things, place new things, change topic colors), however these -- view related -- manipulations are not made persistent. Content manipulations are made persistent (provided the user has WRITE permission to the respective object of course), but view manipulations are not. A topicmap is a view (to content existing elsewhere). The rationale here is to allow the user all the DM freedom to adapt a view to hers personal/situation-based need without undermining access control. So, the current interpretation is: a user who has no WRITE permission to the view (= topicmap) is not allowed to make persistent changes to the view.

comment:2 in reply to: ↑ description Changed 6 years ago by jri

Replying to JuergeN:

[...] I think that only users with write permission on the system workspace should be able to create new users ...

This is realized meanwhile.
See ticket:751#comment:30

comment:3 in reply to: ↑ description Changed 6 years ago by jri

Replying to JuergeN:

It seams that a search|~result is stored in the workspace where I search. What does that mean, if I do not have write permission on a workspace?

Yes, indeed, this let come up the question to which workspace a Search is supposed to be assigned? My suggestion: we always assign a Search to the user's private workspace. A search would appear in the current topicmap (as it is now) but would be assigned to the private workspace, regardless which workspace is selected. From the design perspective the rationale would be: Searches are private. Nobody is supposed to see what another user is searching for.

However, one question remain: where to assign the searches created by anonymous? Anonymous has no private workspace. Searches performed by anonymous are in fact abandoned. So, who is supposed to delete them? Should we assign them to the System workspace, in order to let the "admins" delete them once in a while?

comment:4 Changed 6 years ago by JuergeN

+1 => I agree with both suggestions.

comment:5 Changed 6 years ago by Jörg Richter <jri@…>

In 85a9acacbae735981f48ed400baf693071fdac00/deepamehta:

Search topics are private (#592).

A Search topic is assigned to the user's private workspace.
Nobody can see what another user is searching for.

Pending:
Search topics created by anonymous have no workspace assignment yet.
As a consequence they are not deletable.

Note: assigning Search topics created by anonymous to the System workspace (see #756) is not practicable as anonymous has no READ access to the System workspace. She could not see her own search.

Access Control API

1 new method:

Topic getPrivateWorkspace()

Returns the private workspace of the logged in user. If no user is logged in an exception is thrown.
Note: a user can have more than one private workspace. The workspace returned by this method is the one that holds the user's password topic.

See #592.

comment:6 Changed 6 years ago by Jörg Richter <jri@…>

In f4127c3d33e856f970bc3d09281e27e085926b4c/deepamehta:

Anonymous Search topics (#592, #756).

Search topics created by anonymous are assigned to the DeepaMehta workspace.
As a consequence they are not deletable by anonymous but by DeepaMehta members.

See #592
See #756

comment:7 Changed 6 years ago by jri

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.