How do you manage the owner of a resource when using adonis-acl? In my application the typical pattern is that if you own the resource you have full CRUD over it but Admins also have Updated and Delete control over the resource even though they are not the owners.
Ideally I want to manage this control though middleware rather than having to then re-check ACL in my Controllers. Ideally I'm looking for something like
Route
.get('/users')
.middleware(['auth:jwt', 'is:(administrator)' 'can:read_resouce_{SOMEKINDOFID}'])
Currently is seems that the only way I can do this is to setup a permission for every single resource which for my use case seems unnecessary.
Thanks
Related
After testing authentication in Orion with keycloak (Orion APIs authentication through Keycloak) with kong-pep-plugin, I'm interested in the authorization too; in particular, I want to give specific permissions (on path and verb) to users/groups like I used to do with AuthZForce.
Could you help me?
Thank you
sorry that I only see your request right now. This is very much tied to configuring Keycloak, but it is possible, yes. The kong-pep-plugin delegates all decisions to Keycloak's Authorization Serivces and just takes its decision. Thus, you should read the documentation on that: https://www.keycloak.org/docs/latest/authorization_services/index.html
An example (declarative)configuration for allowing different groups to access different paths can be found in the integration-tests:
https://github.com/FIWARE/kong-plugins-fiware/blob/main/it/src/test/k3s/keycloak.yaml#L518-L567
Another, better readable, example is our demo environment:
https://github.com/FIWARE-Ops/fiware-gitops/blob/master/aws/fiware/keycloak/templates/realmConfigMap.yaml#L139-L203
This combination of resources and policies allows the group "consumer" to access the path "/keycloak/ngsi-ld/v1/", while the group "admin" can also access "/keycloak/".
The authorization services allow for much more fine-grained and powerful configurations, so I really recommend the official documentation on it.
Best
As an addition for the GET/POST question:
Thats something you can implement with the javascript policies feature from Keycloak(keycloak.org/docs/latest/authorization_services/…). The kong-plugin forwards the http method as "http.method" claim(see github.com/FIWARE/kong-plugins-fiware/blob/main/kong-pep-plugin/…)
An example policy could granting access only for GET requests could look like:
var context = $evaluation.getContext();
var attributes = context.getAttributes();
var method = attributes.getValue('http.method').asString(0);
if (method === 'GET')
{$evaluation.grant();
Combining a resource policy with such a js-policy would give you the access-control you want.
I want to restrict calls to a Feathers service method for externals calls with associateCurrentUser.
I also want to allow the server to call this service method without restricting it.
The use case is that through this service then clients use a lock table, all clients can see all locks, and occasionally the server should clear out abandoned rows in this table. Row abandonment can happen on network failures etc. When the server removes data then the normal Feathers remove events should be emitted to the clients.
I would imagine that this should be a mix of associateCurrentUser and disallow hooks but I can't even begin to experiment with this as I don't see how it would be put together.
How would one implement this, please?
Update:
I found this answer User's permissions in feathers.js API from Daff which implies that if the hook's context.params.provider is null then the call is internal, otherwise external. Can anyone confirm if this is really so in all cases, please?
It seems to be so from my own tests but I don't know if there are any special cases out there that might come and bite me down the line.
If the call is external params.provider will be set to the transport that has been used (currently either rest, socketio or primus, documented here, here and here).
If called internally on the server there is not really any magic. It will be whatever you pass as params. If you pass nothing it will be undefined if you pass (or merge with) hook.params in a hook it will be the same as what the original method was called with.
// `params` is an empty object so `params.provider` will be `undefined`
app.service('messages').find({})
// `params.provider` will be `server`
app.service('messages').find({ provider: 'server' })
// `params.provider` will be whatever the original hook was called with
function(hook) {
hook.app.service('otherservice').find(hook.params);
}
How can I configure Polymer's platinum-sw-cache or platinum-sw-fetch to cache all URL paths except for /_api, which is the URL for Hoodie's API? I've configured a platinum-sw-fetch element to handle the /_api path, then platinum-sw-cache to handle the rest of the paths, as follows:
<platinum-sw-register auto-register
clients-claim
skip-waiting
on-service-worker-installed="displayInstalledToast">
<platinum-sw-import-script href="custom-fetch-handler.js"></platinum-sw-import-script>
<platinum-sw-fetch handler="HoodieAPIFetchHandler"
path="/_api(.*)"></platinum-sw-fetch>
<platinum-sw-cache default-cache-strategy="networkFirst"
precache-file="precache.json"/>
</platinum-sw-cache>
</platinum-sw-register>
custom-fetch-handler.js contains the following. Its intent is simply to return the results of the request the way the browser would if the service worker was not handling the request.
var HoodieAPIFetchHandler = function(request, values, options){
return fetch(request);
}
What doesn't seem to be working correctly is that after user 1 has signed in, then signed out, then user 2 signs in, then in Chrome Dev Tools' Network tab I can see that Hoodie regularly continues to make requests to BOTH users' API endpoints like the following:
http://localhost:3000/_api/?hoodieId=uw9rl3p
http://localhost:3000/_api/?hoodieId=noaothq
Instead, it should be making requests to only ONE of these API endpoints. In the Network tab, each of these URLs appears twice in a row, and in the "Size" column the first request says "(from ServiceWorker)," and the second request states the response size in bytes, in case that's relevant.
The other problem which seems related is that when I sign in as user 2 and submit a form, the app writes to user 1's database on the server side. This makes me think the problem is due to the app not being able to bypass the cache for the /_api route.
Should I not have used both platinum-sw-cache and platinum-sw-fetch within one platinum-sw-register element, since the docs state they are alternatives to each other?
In general, what you're doing should work, and it's a legitimate approach to take.
If there's an HTTP request made that matches a path defined in <platinum-sw-fetch>, then that custom handler will be used, and the default handler (in this case, the networkFirst implementation) won't run. The HTTP request can only be responded to once, so there's no chance of multiple handlers taking effect.
I ran some local samples and confirmed that my <platinum-sw-fetch> handler was properly intercepting requests. When debugging this locally, it's useful to either add in a console.log() within your custom handler and check for those logs via the chrome://serviceworker-internals Inspect interface, or to use the same interface to set some breakpoints within your handler.
What you're seeing in the Network tab of the controlled page is expected—the service worker's network interactions are logged there, whether they come from your custom HoodieAPIFetchHandler or the default networkFirst handler. The network interactions from the perspective of the controlled page are also logged—they don't always correspond one-to-one with the service worker's activity, so logging both does come in handy at times.
So I would recommend looking deeper into the reason why your application is making multiple requests. It's always tricky thinking about caching personalized resources, and there are several ways that you can get into trouble if you end up caching resources that are personalized for a different user. Take a look at the line of code that's firing off the second /_api/ request and see if it's coming from an cached resource that needs to be cleared when your users log out. <platinum-sw> uses the sw-toolbox library under the hood, and you can make use of its uncache() method directly within your custom handler scripts to perform cache maintenance.
I have a custom permission model for my project and I'm not using django's default permissions backend. I have a custom has_permission template tag to check if the user has the specified permission or not.
The problem is that there's lots of queries done for the same checks every time, I'm looking for a way to reduce my Permission queries. What I'm doing inside my templates is like :
{% if user|has_permission:'jpermission.can_edit_jpermission' or
user|has_permission:'jgroup.can_edit_jgroup' or
user|has_permission:'role.can_edit_role' %}
and the code for has_permission template tag is as follows :
rep = perm_name.split('.') # rep is for e.g. "jpermission.can_edit_jpermission"
ctn_type = rep[0]
codename = rep[1]
pr = JPermission.objects.filter(model_name=ctn_type, codename=codename)
if pr.exists():
if user.has_perm(pr[0]):
return True
Specifically talking, the problem is that every time i check even for the exactly same if statements, lots of queries are made (from what I'm doing, it's obvious there will be).
Is there any other way i can go at it ? like query all permissions once, cache them, and do something like how prefetch_related is handled to prohibit further db queries (python filtering with loops and ... ) ?
P.S: has_perm is also overridden and checks if users role, group or permissions have the specified permission or not)
There are multiple solutions for this.
Move permissions to user model as methods of model and use cached_property decorator so that consecutive calls to methods does not hit database again.
Store the permissions state in session when user logged in, and later use session data to check for permissions.
It looks like you are using django-guardian, and it is already caching the permissions:
Once checked for single object, permissions are stored and we don’t
hit database again if another check is called for this object. This is
great for templates, views or other request based checks (assuming we
don’t have hundreds of permissions on a single object as we fetch all
permissions for checked object).
I am unable to load an iWidget externally on the communities page
This is my widget def:
<widgetDef defId="qmiWidget" primaryWidget="false" modes="view fullpage edit search"
url="http://questionmine.com/app1/widgets/index/publishProject_iWidget"/>
But it replaces the http and tries to load it internally
"NetworkError: 403 Forbidden - https://connectionsww.demos.ibm.com/communities/ajaxProxy/http/questionmine.com/app1/widgets/index/publishProject_iWidget"
Any idea how can I do this ?
Since your widget resides on another domain, you have to configure the "Ajax Proxy" to allow this.
Take a look at this here:
http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp?lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Configuring_the_AJAX_proxy_ic45&content=pdcontent
For testing purposes (ONLY testing) it would be safe to allow "*" but for a production environment it is strongly advised to be more specific, in your case something like "questionmine.com/app1/*"
You can even configure specific proxy rules per application (Communities, Profiles, Homepage,...)
http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp?lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Configuring_the_AJAX_proxy_for_a_specific_application_ic45&content=pdcontent
BTW: If you ever tried to enable feeds in a community, the same applies. Without further configuration, only same-domain feeds would be allowed.