etchuk / etch.orchardcore.contentpermissions Goto Github PK

In addition to allowing frontend authorization on individual content items, it would also be useful if the same settings could be used to configure who should have access to the page's edit form in the admin.

Of course, the ideal extension of that would also be having the ability to filter out such items from lists displayed in the admin, but I'm not sure whether there's even any sort of filtering mechanism like that built into OrchardCore.

The use case is having multiple levels of access in the admin where certain pages are accessible only to the administrator and a specific subset of admin users, but other pages of the same content type will be accessible to everyone who has admin access.

The way it is currently written, it seems like it's possible for a lower-level admin user to create a page that the Administrator doesn't have the ability to view. Of course, the Administrator could just change it back, but it still doesn't make any sense that the Administrator could be locked out of anything in the first place. There should be an exception made in the DisplayDrivers to guarantee that the Administrator is always marked as a valid role for a given ContentItem and that their access is not prohibited.

This is especially important for #14 which would enable a user on the backend to prevent an Administrator from even editing the content item.

It would be a nice enhancement to be able to hide a ContentItem from flow / bag, with maybe with an optional message that would replace the widget if a user is not permitted.

Seeing 74144c1. I suggest checking out this reusable workflow we've created for NuGet publishing: https://github.com/Lombiq/GitHub-Actions/blob/dev/Docs/Workflows.md#nuget-publish-workflow Apart from pushing the package to NuGet, it also manages the version number in the Manifest and assembly, adds Source Link, creates and pushes a symbols package, and create a release on GitHub.

Hi

Would it be possible to extend this function to workflows? For example preventing people from certain roles to edit or create new workflows or at least limit the number they can own?

I have a use case in which we will be relying on either LDAP groups or ad-hoc username groups to control access to individual pages. These collections will naturally grow in size over time. Porting over from an existing system, we likely have well over a thousand combinations of users able to access various pages across hundreds of sites. Using the current mechanism, we would need to generate Roles for every single one of these groups (not satisfactory).

I would propose developing a separate module for group abstraction that can then be made a dependency of this module. It would then rely on the group services to locate information with which to compare access level authority, and would rely on registered services both for collecting the data and performing the evaluations of said data. In this way, third-party modules would be able to dictate not only what data is used to determine content item permissions, but also how that data should relate to existing information in the Orchard Core CMS.

It seems to me that if a tenant URL prefix is configured then that should be included in the redirect URL, making the DB not portable between environments if the prefix is different (or doesn't exist). Adding support for tilde-prefixed URLs would solve this. E.g. "~/" would redirect to the tenant's homepage, regardless it having a URL prefix or not.

when i add this code in the liquid template like this：
`{% if Model.ContentItem | user_can_view %}

Awesome content that you have permission to view.

Unfortunately you're not able to view this content.

{{ Model.Content.ContentsMetadata | shape_render }}
{{ Model.Content.MarkdownBodyPart | shape_render }}
{{ Model.Content.BlogPost-Category | shape_render }}
{{ Model.Content.BlogPost-Tags | shape_render }}
{{ Model.Content.CommentatorPart | shape_render }}`

run the app,throw this exception：

An unhandled exception occurred while processing the request. Exception: Failed to parse liquid file /Areas/TheBlogTheme/Views/Content-BlogPost.liquid: Invalid 'if' tag at (31:6) Source: {% if Model.ContentItem | user_can_view %} OrchardCore.DisplayManagement.Liquid.LiquidViewTemplate+<>c__DisplayClass8_0+<<ParseAsync>b__0>d.MoveNext() in LiquidViewTemplate.cs, line 98

Can this module also be used to set content item level permissions by code? Or is this something that would still be needed to be done manually by an administrator?
Or maybe setting item level permissions by code is possible regardless of this module but this module will make sure that such permissions work on the content items?

At the moment, if you fail to configure a Redirect URL it ignores all of the permission checks with the assumption that every view has had access checking code applied.
From a security aspect this is the worst possible scenario, as we are saying that by default we allow access if the user fails to specify a redirect, whereas it makes more sense to say that there is either an overarching default destination (even if it's the site root) or actually throw the default 403 so the developer knows they've left a gaping hole in their security, and the system can use the Orchard.Diagnostics module to handle the error?
Am I missing something in the way this is supposed to be handled?

The module currently applies only to pages. When I try to add the Content Permissions Part to menu item (CustomLink or ContentLink), it doesn't affect rendering of the menu. I've tried to find some way how to implement this and extend the module, but can't get to it. Use some filter maybe?

Firstly, great module, very usefull.
Do you think this can be extended to set permissions at user level ?
Example, I wish to share a content item to a system user (granting readonly, or edit permissions) ,similar to google docs which allows you to share a document to a user by his email.
Thanks again.

Support that instead of a redirection an unauthorized user instead sees a 404 page. The redirect tells that "something is there" which might be a security issue. Showing a 404 (like GitHub does too), intentionally not a 401, is better because that would again tell about the existence of the item.