In most apps there is the need to scope cached queries by default. Let's say you allow users to use multiple accounts. You'd probably want to scope each and every query to the account the user uses.
If queries are not scoped by default, we have to pass the accountId to every invocation of useQuery like so: useQuery([accountId, ...]).
I'd love to know if queryFn can be bound to a global key like this.
<QueryClientProvider client={queryClient} defaultKey={[accountId]}>{...children...}</QueryClientProvider>
Related
So I'm sending all users through apache with mod_auth_kerb. All users come in with a default userRolesHeader of users.
I'd like to add extra roles for specific accounts, but I'm not seeing a good way to do that. If you could define the users in realm.properties and it would combine with the userRolesHeader, that would be useful.
Is there another way to do this? I don't see how it can be done with apache alone since REMOTE_USER isn't available during if/else logic processing.
#rundeck
rundeck.security.authorization.preauthenticated.userNameHeader=X-Forwarded-Uuid
rundeck.security.authorization.preauthenticated.userRolesHeader=X-Forwarded-Roles
#apache
RequestHeader set "X-Forwarded-Uuid" %{REMOTE_USER}s
RequestHeader set X-Forwarded-Roles users
Internally Rundeck gets only one method once, if you configure Rundeck to get the users from the realm.properties file, Rundeck seeks the roles from that file. Currently You can combine methods but the user/role in different methods doesn't.
For my use case, I would like to add certain attributes(derived from roles) to all the JWTs. And this would be needed for multiple clients. Is there a way to define mappers for all the clients under a realm in a given Keycloak instance?
No, you can't define "global mappers".
Scope can be used for this "global" approach. Use some your default scope (scope which is executed implicitly), which is default for all your clients, (for example profile scope usually) and define your "global" mapper(s) there.
Consider a multi-tenant firestore database:
/customers/{customerId}/users/{userId}/rosters/{rosterId}
Since it seems collectionGroup is scoped to the entire database. So in node:
let rosters = db.collectionGroup('rosters').where('isActive', '==', 'true');
would return matches for all customers. For client side this can be scoped through security rules.
How can it be scoped in admin access?
Collection group queries are applied to all collections that have the name you specify. There is currently no way to scope them beyond that. Long term the plan is to allow scoping to paths, but there's no timeline for when that might be available, and it definitely won't be in the near future.
This means that you'll either need to be able to reduce the scope through the collection name (e.g. if you'd have multiple types of rosters, you might want to rename the collections under users to user_rosters so that you can limit a collection-group-query to just user's rosters), or through additional field conditions in your query.
While the latter case might feel like you're going back to global collections, it's actually still better than that, since the subcollections do result in better write throughput.
We have a situation where we have two different roles of users: let's call them content_labourer and content_boss. There's a template we could call very_cool_content. On this template we've stated the following attributes:
title: some string value
api_content_id: an integer that accurately binds this content to some backend API content (we use this in our VeryCoolContentController to fire up some backend API stuff, obviously)
description: a text value
I want my content_boss to be able to set the value for all these attributes. After all, he's the boss.
However, my content_labourer is not privy to the whole API business and would never in a million years know which value he should enter there, let alone that he should even be able to enter/change the value of api_content_id. He should also not be able to set the value of title, because that's none of his business.
Now my question is: how do I protect these particular attributes from being changed by (or in the ideal case: even be visible to) users without the content_boss role?
I am sorry, but it is not possible to restrict access to single fields. But what you can do is to restrict the access to an entire page. Maybe you can make use of that instead, if you restructure your content somehow?
Would it be viable to use an embedded document roles field for a user table if at most there can be 5 different roles? The reason I ask this is because I believe using an array type for that field would do the same thing. The only time I'd be using the roles field is for checking if the user has the ability to access certain pages/functionality on the website. Am I missing something here? Thanks
I don't really think either approach is incorrect and I think it's more relevant to how you want your models to look than how your data will be stored. It really just depends on what (if any) information aside from the role type that you want to persist and how you plan to check the user's role.
If you're looking to simply store a list of roles (admin, user, moderator, etc) then a serialized array attribute is probably fine. On the other hand, if your roles have more information stored within them (ex. granted actions or privileges for each role) it might be beneficial to build out a UserRole model separately and embed that in your User model.
There is actually another, pretty good option if you're simply storing a list of roles where each user can be a member of one or more roles. You can actually us a bitmask. Using this approach your user roles would be stored as a simple integer and you'd use some of ruby's bitwise operators to map that value to a set of roles.
http://railscasts.com/episodes/189-embedded-association?view=asciicast