I have a field in a cq5 component that I don't want made public. Is there any way to restrict a field so its only available through a jsp call or some other method on the server but not available if you request information from a JSON call?
One method may be to create the private field on a child node of the node that has the public field. Then use user permissions to restrict the access to that child node. In the server side code you'd need to access it via an account that has permission to read it.
Another option may be to encrypt the private value so that even though it is viewable via the .json url, it is meaningless. The server side code would have the key to decrypt it so it would be usable there.
I don't think you can set permissions on properties in CRX--I believe the security model applies the permissions only at the node level. Per the JCR specification:
16.3.9 Access to Properties
Access to a property is controlled by the effective access control
policies of its parent node.
Related
In my current project I'm working with StreamSets and I would like to use Hashicorp Vault as my credentials store, however I'm not able to use credential:get() function wherever I want to. E.g. in Shared Access Key in Azure IoT Hub Producer block. I know that I could use Runtime Properties but I don't think it solves my problem.
Am I missing something or I can use credential:get() only in fields marked with a key icon?
You can only use credential:get() in fields marked with a key icon. This is by design, to minimize the chance of leaking credentials. For example, if credential:get() was allowed in URL parameters, a pipeline designer could send a request to a web server under their control to discover the credential. It may make sense to allow Shared Access Key to receive credentials. Please file an issue at https://issues.streamsets.com with your enhancement request.
I'm working with Shopware.
I've added a new attribute "proxy" to the s_core_auth table for each user in order to show the ability to get access to the Customer Module in the backend, so that if a user is not selected as "proxy" he/she won't be able to make changes in that module.
I need help to understand what I need to write in my plugin's code (maybe having only a Subscriber file.)
I'll be very grateful!
Adding a custom column to the s_core_auth table is not a good idea. What you're trying to achieve can be done with user groups and group rights. From the Shopware Documentation:
With User administration you are able to create new users in the backend and control access rights to areas, modules and plugins in accordance with certain group policies that you define per ACL (Access Control List). Within the ACL you have the possibility to control precisely which user is able to perform which activity. Thus, it is possible to assign certain reader rights to an administration group without granting them authorization to edit or delete.
You can find instructions for User administration inside the Documentation.
Trying to build an authenticated page with components that request data about the authenticated user from a backend service. The idea is that the authN response from the backend be as light as possible (e.g. a userID and authToken) and the components on the page would use those to make subsequent calls to retrieve further details, but I'm not quite sure the best way to share that data/context for all components on the page to access.
What's the best way to have that context shared?
You have a few options. You can set variables in components that scope them to apply beyond just that JSP. See http://www.java2s.com/Code/Java/JSTL/JSTLSetVariablesScope.htm
With scoping you can make variables accessible with session scope or request scope so that once set any other components that are processed during the same request will be able to access the variables.
So you could make your authentication component set variables with request scope for the userID and authToken, and then subsequent components would be able to access those variables and use them for their needs. An example is shown in https://stackoverflow.com/a/21352909/230055
I have a user:
GET /user/1 -> {id:1,name:"john"}
My authorization engine makes sure that anyone can GET /user/1, but PUT /user/1 or PATCH /user/1 is restricted to john himself or a system admin.
How do I handle parts of the user that can only be modified by an admin? For example, what if I have a property blocked, which determines if the user is allowed to log in? For obvious reasons, john should not be able to change his blocked status, only an admin should.
I see two ways to do this:
Make permissions a completely separate resource, accessible either at /permissions/:user or /user/:user/permissions, and allow only admins to access that path. Thus PUT and PATCH to /user/:user can change the user all it wants, it really only modifies user-modifiable data, while /permissions is admin-modifiable data
Make permissions built into the user-object, but do logic within the PUT or PATCH handler to prevent anyone other than admin from modifying it.
Option 2 keeps the user object intact, while option 1 allows me to completely encapsulate and separate data the user or an admin can change from data only an admin can change.
The difference between the PUT and PATCH requests is reflected in
the way the server processes the enclosed entity to modify the
resource identified by the Request-URI. In a PUT request, the
enclosed entity is considered to be a modified version of the
resource stored on the origin server, and the client is requesting
that the stored version be replaced. With PATCH, however, the
enclosed entity contains a set of instructions describing how a
resource currently residing on the origin server should be modified
to produce a new version. The PATCH method affects the resource
identified by the Request-URI, and it also MAY have side effects on
other resources; i.e., new resources may be created, or existing
ones modified, by the application of a PATCH.
According to the PATCH method definition.
I did not find anything about how to define full and partial terms, so it is probably up to you. So in the actual auth context the full can mean everything the current user has access to, and the partial can mean less than full.
So there is nothing wrong if you don't send the permissions in a PUT when your user cannot modify the permissions, just an admin.
So permissions can be a both a sub-resource and a separate resource or even part of a separate security service.
I am new in apache shiro, and I read almost 60% of tutorials in apache shiro page.
It is a wonderful framework, however I wonder if it can meet my requirements.
I am interested in the permission-based authentication.
For example, to make sure if the user have the permission of delete resources, we can use this:
currentUser.isPermitted( "resource:delete" );
However in our application, even a user have the permission of delete resources, he can only delete some specified resources, not all of them.
For example(just an exmaple), the resource have an filed named createdby to record the one who create this resource.
Now user can only delete the resources created by himself if he have the resouce:delete permission.
In fact, the resources which can be deleted by the user(who have authenticated and have delete permission) will be calculated by more constraints.
Now how to make shiro work in this suitation?
You can do this in Shiro but you will have to write some code. Either create a subclass of Authorizer and inject it into the security manager or create a subclass of one of the realm classes such as JdbcRealm. Then override the isPermitted method. This will need to have access to your permissions model, for example the database table or a document in a NoSQL database.
Your call to isPermitted will need to specify the resource you are deleting so you can look it up in your overridden method.
If you override the isPermitted method in the AuthorizingRealm subclass you will have access to the logged in user's principals and the user's Roles: this gives you quite a bit of flexibility because you can have says: user (principal) Fred with roles: Manager, Administrator. Your permissions model can then decide if Fred, a Manager or and Administrator can perform the task on the specified resource.
Hope that gives you some ideas.
From the extent, I have explored Shiro, I don't think it gives that level of flexibility to have a customized check. It basically functions based on roles and permission defined in the config file.
For this functionality I would suggest that you display only those records the user is allowed to delete, by have this check at query fetch level. (or) add a condition at the UI level not display the delete button if logged in user is same as created by. This is just a suggestion.