I'm checking if any of the user's roles are part of a document's allowed roles. The following should match since the user is an admin+editor, and the post allows reading by publisher+editor:
service cloud.firestore {
match /databases/{database}/documents {
match /group/{groupId} {
match /posts/{postId} {
allow read: if 'admin,editor'.matches('((,|^)(publisher|editor)(,|$))');
}
}
}
}
Here's it working in a regex tester: https://regex101.com/r/bDXMg3/2/
But this fails to match, any ideas?
Our docs could be clearer on this, but it looks like the whole string needs to match. Give (.*,|^)(publisher|editor)(,.*|$) a try.
Related
I am making a Jira REST API call using this example url:
http://example.com/rest/api/2/search/?jql=project=example%20and%20type=test&fields=customfield_14600
Here is an example of the returned JSON
{
"expand":"names",
"startAt":0,
"maxResults":50,
"total":2,
"issues":[
{
"expand":"examples",
"id":"1111",
"self":"https://example.com/rest/api/2/issue/111111",
"key":"EX-1111",
"fields":{
"customfield_14600":{
"self":"https://example.com/rest/api/2/customFieldOption/1111",
"value":"Common",
"id":"11111",
"disabled":false
}
}
},
{
"expand":"examples",
"id":"1111",
"self":"https://example.com/rest/api/2/issue/111111",
"key":"EX-1111",
"fields":{
"customfield_14600":{
"self":"https://example.com/rest/api/2/customFieldOption/1111",
"value":"Uncommon",
"id":"11111",
"disabled":false
}
}
}
]
}
Here is an image of the returned JSON with better formatting
What URL would I use to only return the issues with the value "Common" for the customfield_14600? Basically I am trying to return the number of issues with the "Common" value.
Thank you.
Hello Yousuf and welcome to StackOverflow.
Since you are using a JQL query, you could add another filter to check that the custom field you need has the value you require, as such:
project = example AND type = test AND cf[14600] = "Common"
Or, if you know the name of the custom field and/or prefer it to be readable:
project = example AND type = test AND "Field name" = "Common"
You can check the manual for more operators/keywords.
On another topic, I would recommend using the POST endpoint instead of the GET one for searches that include complex queries. Check the REST API documentation for instructions.
The decisioning is to permit if the user has required roles. The required roles and the user's current permissions are in JSON format.
Required permissions: (Saved as a attribute)
{
"data": {
"service1": {
"service1.1": true
},
"service2": {
"service2.1: false,
"service2.2": true,
"service2.3": false
}
}
}
User's current permissions:
{
"data": {
"service1": {
"service1.1": true
},
"service2": {
"service2.1: false,
"service2.2": false,
"service2.3": true
}
}
}
To make the decision, we need to check if the user has the services as true similar to required Permissions. In the above example, the user has data.service1.service1.1 as true and data.service2.service2.3 as true where the required roles being data.service1.service1.1 as true and data.service2.service2.2 as true, in this case we deny.
I wrote separate rules to check for each and every service, but that would only be a check of combination of services.
rule service1.1{
permit
condition
(allOf(function[booleanEqual], true, requiredRoles.data.service1.service1.1))
&&
(allOf(function[booleanEqual], true, requiredRoles.data.service1.service1.1))
on permit {
advice reasonForPermit{
reasonAttribute= "Contains Valid services"
}
}
}
Would someone please help on how to write a if.. then check in alfa?
There is no if..then construct in ALFA (or XACML). You use combining algorithms instead. In particular, onPermitApplySecond is the policy combining algorithm that resembles an if..then construct the most.
However, there is usually a simpler way to express what you want if you can make reasonably assumptions on your attribute data. In your example, for instance, if it's always guaranteed that both the required and current permissions contain exactly one boolean value for each available service, then you could write:
rule {
target
clause requiredRoles_service1_1 == false or permitted_service1_1 == true
clause requiredRoles_service2_1 == false or permitted_service2_1 == true
...
permit
}
Remember that in a target, clauses are AND'ed together. This rule then checks that, for every service, the role is either not required or is given in the current permissions.
If instead it may happen than any of those attributes is not present (i.e. there are no values for the attribute), then you have to guard against that case. You can do that using a condition like the following one, but there are other ways too:
rule {
permit
condition
(not(booleanIsIn(true, requiredRoles_service1_1)) || booleanIsIn(true, permitted_service1_1))
&&
(not(booleanIsIn(true, requiredRoles_service2_1)) || booleanIsIn(true, permitted_service2_1))
&&
...
}
All in all, there are usually simpler ways to express a policy if you can massage attribute data into other forms. Having a pair of attributes per service, like in the examples above, may not be necessary.
If you could gather all required roles and current permissions in one attribute each, then the policy can be expressed much more compactly. Let's say you have two attributes, requiredRoles and permittedRoles whose values list the service roles required and permitted for a given user, respectively. In your example, this would mean that requiredRoles has value, say, ["service1.1", "service2.2"] and permittedRoles has value ["service1.1", "service2.3"]. Then you can write a rule like this:
rule {
permit
condition stringSubSet(requiredRoles, permittedRoles)
}
I was able to do this by creating separate attributes for each service and wrote a rule with the target clause with the service from required roles and the condition will be if the service in the permitted role is true. I combined all the rules as below in the policy using permitunlessDeny algorithm
rule rule1 {
target clause requiredRoles.service1_1 == true
deny
condition
not(permittedRoles.service1_1 == true)
on permit {
advice reasonForPermit {
reasonAttribute= "User has valid services"
}
}
}
Thank you for the suggestion Pablo.
I mean I know what those are but I am a bit confuse about the security rules, for example:
service cloud.firestore {
match /databases/{database}/documents {
// This is probably a mistake
match /spaceships { // <= what is this a collection or a document?
allow read;
// In spite of the above line, a user can't read any document within the
// spaceship collection.
}
}
}
Firebase documentation says:
Rules for collections don't apply to documents within that collection. It's unusual (and probably an error) to have a security rule that is written at the collection level instead of the document level.
That means that this match /spaceships {... is a collection right?
But later on we have this:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**}{ // <= what is this a document or a collection?
allow read, write: if true;
}
}
}
I don't understand is this match /{document=**}{... a document? or a collection? I mean is at the collection level.
Paths in Firestore are alternating collections and documents: /collection/document/subcollection/subdocument
For example:
// Matches kaylee, the mechanic on serenity
/spaceships/serenity/crew/kaylee/...
When using security rules, you can specify wildcards:
// This will match any spaceship, and any crewmember
/spaceships/{spaceshipId}/crew/{crewmemberId}/...
Now imagine that you have another subcollection under spaceships:
/spaceships/{spaceshipId}/stowaways/{stowawayId}/...
If you want to write rules against multiple subcollections, you need to either:
// You could use multiple single wildcards
/spaceships/{spaceshipId}/{crewOrStowaway}/{crewOrStowawayId}/...
// Or you could use a multi-segment wildcard
/spaceships/{spaceshipId}/{allShipInformation=**}
This returns allShipInformation as a path, which will match all documents and collections at and below that path. Note that it's one or more path segment, rather than zero or more.
You can read more about this in the docs
In your first example /spaceships is at the collection level. As was stated in the quote you referenced, placing a rule here is not helpful as it won't be applied to any of the documents in the collection.
In your second example /{document=**} is at the collection level but is using a recursive wildcard. In short, what this does is apply the rule to the documents within this collection and to any documents within any subcollections of this collection.
This allows you to write:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**}{
allow read, write: if true;
}
}
}
Instead of:
service cloud.firestore {
match /databases/{database}/documents {
match /spaceships/{shipId} {
allow read, write: if true;
}
match /spaceships/{shipId}/crew/{crewMemberId} {
allow read, write: if true;
}
}
}
I want to write a JSON API.
My problem is, that sometimes I want to query for an ID, sometimes for a String.
One option would be to add a querystring, for example:
example.com/user/RandomName
example.com/user/1234556778898?id=true
and use it like:
api.get('user/:input', function(req, res) {
if(req.query.id) {
User.find({ '_id': req.params.input }, cb);
} else {
User.find({ 'name': req.params.input }, cb);
}
};
But this seems like bad practice to me, since it leads to a bunch of conditional expressions.
Are there more elegant ways?
I would suggest handling two endpoints. One for getting ALL the users and one for getting a SPECIFC user by ID.
example.com/users
example.com/users/:id
The second endpoint can be used to find a specific user by id.
The first endpoint can be used to find all users, but filters can be applied to this endpoint.
For example: example.com/users?name=RandomName
By doing this, you can very easily create a query in your Node service based on the parameters that are in the URL.
api.get('/users', function(req, res) {
// generate the query object based on URL parameters
var queryObject = {};
for (var key in req.query) {
queryObject[key] = req.query[key];
}
// find the users with the filter applied.
User.find(queryObject, cb);
};
By constructing your endpoints this way, you are following a RESTful API standard which will make it very easy for others to understand your code and your API. In addition, you are constructing an adaptable API as you can now filter your users by any field by adding the field as a parameter to the URL.
See this response for more information on when to use path parameters vs URL parameters.
Meteors loginWithPassword() function doesn't provide me the object systemData, which I adding to user doc (not to profile obj) during registration. The thing is, that if I look into console after logging in, I can see that object systemData (that means probably it's not publish issue), but not in callback of loginWithPassword() function, where I need them (to dynamically redirect user to proper page). Is there way to get this object, without any ugly things like timers?
Meteor.loginWithPassword(email, password, function(errorObject) {
if (errorObject) {
...
} else {
// returns true
if (Meteor.userId()) {
// returns false
if (Meteor.user().systemData) {
...
}
// user doc without systemData object
console.log(JSON.stringify(Meteor.user());
}
}
I've adding object systemData on creating user:
Accounts.onCreateUser(function(options, user) {
if (options.profile) {
user.profile = options.profile;
}
...
user.systemData = systemDataRegularUser;
return user;
});
Are you sure publish data to Client ?
I get User Info Using loginWithPassword in callback function.
Meteor.loginWithPassword username,password,(error,result1)->
options =
username: username
password: password
email: result['data']['email']
profile:
name: result['data']['display-name']
roles: result.roles
console.log Meteor.user(), result1
I Create user flowing code: (options contains systemData)
Accounts.createUser option
The first problem is that you want a custom field on a user document published to the client. This is a common question - see the answer here.
The next problem is that even after you add something like:
Meteor.publish("userData", function () {
return Meteor.users.find(this.userId, {fields: {systemData: 1}});
});
I think you still have a race condition. When you call loginWithPassword, the server will publish your user document, but it will also publish another version of the same document with the systemData field. You are hoping that both events have completed by the time Meteor.user() is called. In practice this may just work, but I'm not sure there is any guarantee that it always will. As you suggested, if you added a slight delay with a timer that would probably work but it's an ugly hack.
Alternatively, can you just add systemData to the user's profile so it will always be published?
I didn't find exact way how to solve this, but found easy workaround.
To make some action right after user logged in (eg. dynamically redirect user to proper page), you can hook on your home page with Iron router.(If you using it.) :
this.route('UsersListingHome', {
path: '/',
template: 'UsersListing',
data: function() { ... },
before: function() {
if (isCurrentUserAdmin() && Session.get('adminJustLogged') !== 'loggedIn') {
Router.go('/page-to-redirect');
Session.set('adminJustLogged','loggedIn');
}
}
});
After click on logout of course if (isCurrentUserAdmin()) { Session.set('adminJustLogged', null); }
I've further thought about calling Meteor.call('someMethod') to fetch userData object in Method callback, but now I'm satisfied.
PS: I know that it's not recommended to have plenty session variables or other reactive data source for speeding-up my app, but I believe, that one is not tragedy :)
PS2: Anyway, thanks for your answers.