I have created multiple authorization policies, each with 1 claim in it, doing a role check, like so:
options.AddPolicy("SuperAdminPolicy", policy => policy.RequireClaim(ClaimTypes.Role, "SuperAdmin"));
That all works fine.
However, I'm now at the point where I want to check 2 different types of claims, e.g. I want to make sure that the user has a specific role claim (As above), but I also want to check the value of a completely different claim (Such as first name). To clarify, I want to say something like " user must be in role 'x' and must have a first name claim value of 'bob'".
I can't quite figure out how to achieve this (And I'm sure it's probably quite straight forward).
Can someone point me in the right direction please?
Thanks.
We can actually chain the RequireClaim like this.
services.AddAuthorization(option => {
option.AddPolicy("SuperAdmin policy",
policy => policy.RequireClaim(ClaimType.Role,"SuperAdmin")
.RequireClaim(ClaimType.Name,"Bob"));
});
I did a little additional research on this post as I was looking for something very similar. I noticed there is a policy.RequireRole and policy.RequireUser in addition to RequireClaim. Thus, a policy can require a claim, role, user, or any combination.
Also you can add multiple arguments to the RequireClaim statement for Example If you want to accept multiple Roles:
options.AddPolicy("AdminPolicy", policy => policy.RequireClaim(ClaimTypes.Role, "SuperAdmin" , "Admin"));
Related
I have a Firebase project where I'd like for users to be able to see when other users created their profiles. My initial hope was that I could use "user.metadata.creationTime" on the frontend to pass the date into the user's extra info document and verify that it is correct by having "request.resource.data.datecreated == request.auth.metadata.creationTime" as a Database Rule, but it looks like it is not possible according to the documentation.
Is there any way I can verify that the creation date is correct on the backend?
More info edit: Below is the code that is being triggered when a user creates a new account on my profile. The three values are displayed publicly. I'm creating a niche gear for sale page so being able to see when a user first created their account could be helpful when deciding if a seller is sketchy. I don't want someone to be able to make it seem like they have been around for longer than they have been.
db.collection('users').doc(user.uid).set({
username: "Username-156135",
bio: "Add a bio",
created: user.metadata.creationTime
});
Firestore rules:
match /users/{id} {
allow get;
allow create, update: if request.resource.data.username is string &&
request.resource.data.bio is string &&
request.resource.data.created == request.auth.metadata.creationTime;
}
user.metadata.creationTime, according to the API documentation is a string with no documented format. I suggest not using it. In fact, what you're trying to do seems impossible since that value isn't available in the API documentation for request.auth.
What I suggest you do instead is use a Firebase Auth onCreate trigger with Cloud Functions to automatically create that document with the current time as a proper timestamp. Then, in security rules, I wouldn't even give the user the ability to change that field, so you can be sure it was only ever set accurately by the trigger. You might be interested in this solution overall.
Say that I have node user, item and user_items used to join them.
Typically one would(as advised in official documents and videos) use such a structure:
"user_items": {
"$userKey": {
"$itemKey1": true,
"$itemKey2": true,
"$itemKey3": true
}
}
I would like to use the following structure instead:
"user_items": {
"$userKey": {
"$itemKey1": 1494912826601,
"$itemKey2": 1494912826602,
"$itemKey3": 1494912826603
}
}
with values being a timestamp value. So that i can order them by creation date also while being able to tell the associated time. Seems like killing two birds with one stone situation. Or is it?
Any down sides to this approach?
EDIT: Also I'm using this approach for the boolean fields such as: approved_at, seen_at,... etc instead of using two fields like:
"some_message": {
"is_seen": true,
"seen_timestamp": 1494912826602,
}
You can model your database in every way you want, as long as you follow Firebase rules. The most important rule is to have the data as flatten as possible. According to this rule your database is structured correctly. There is no 100% solution to have a perfect database but according to your needs and using one of the following situations, you can consider that is a good practice to do it.
1. "$itemKey1": true,
2. "$itemName1": true,
3. "$itemKey1": 1494912826601,
4. "$itemName1": 1494912826601,
What is the meaning of "$itemKey1": 1494912826601,? Beacause you already have set a timestamp, means that your item was uploaded into your database and is linked to the specific user, which means also in other words true. So is not a bad approach to do something like this.
Hope it helps.
Great minds must think alike, because I do the exact same thing :) In my case, the "items" are posts that the user has upvoted. I use the timestamps with orderBy(), along with limitToLast(50) to get the "last 50 posts that the user has upvoted". And from there they can load more. I see no downsides to doing this.
In the documentation here, Bloomberg does not make a distinction in the request. The requests can only have 3 things:securities, fields and overrides.
So what are options? How do they get used? Is this a distinction imposed by Rblpapi? Can someone explain the distinction?
Please let me know if I am incorrectly understanding something.
Options are parameters that change how a Request or Subscription should behave. For example, a ref data request with returnEID=true will return the EID(s) of each security in response messages. A Subscription with interval=5.0 will make it an Intervalized Subscription.
Overrides, on the other hand, are field/value pairs that you specify in Requests to alter the form or content of the returned fields, for example, GICS_SECTOR_NAME will normally return sector name in English (or precisely the default terminal language), you can specify SECURITY_NAME_LANG=9 override to get the name in Korean. You can also "request" SECURITY_NAME_LANG field to know the language used in GICS_SECTOR_NAME field. Overrides can be used in Request/Response only (not subscriptions), and are applied to the entire request, on all fields that react to that override.
option.names = "optName", option.values = "optVal"
in R, maps to:
request.set("optName", optVal);
in Java. E.g:
option.names="periodicitySelection", option.values="MONTHLY")
request.set("periodicitySelection", "MONTHLY");
In my project I provide api for a mobile app , and in every api the front end use session_id to mark user authenticity, and in the server side accept and validate it.
Recently we want to use ELK(elasticsearch, logstash, kibana) to preserve and analyze web server access log to extract some commonly occurred user activities. I encountered some problems, I wanna change session_id in the log to user_id(in program I can get user_id from session_id through query database) but I just don't know how?
Can logstash's filter do this? or should I change data when log was indexed in elasticsearch?
Alright, I try to give you an answer assuming that you have some kind of interface from which you can retrieve the user_id. Actually you need to do two things:
Split your log line into separate fields to have a field which contains your session_id
Get the corresponding user_id using some kind of api
Split your log line
You need to split your input into separate fields. This could be done with filters like grok and/or kv. Take a look at some SO questions to find a matching grok pattern or use the grok debugger. Please provide a few log lines if you need help with that.
EDIT: For your given examples your configuration should look something like this:
filter {
grok {
match => [ 'message', '"%{WORD:verb} %{URIPATHPARAM:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} (?:%{NUMBER:bytes}|-) (?:"(?:%{URI:referrer}|-)"|%{QS:referrer}) %{QS:agent} %{QS:xforwardedfor}' ]
}
kv {
field_split => "&?"
}
}
Please try it and adjust it yourself to get the session_id.
Once you have a field called session_id you can go on with step 2.
Get the user_id
As you have already mentioned you need a filter plugin because the session_id must be available. There are several official plugins but I think none of them suits your purpose. Since the session_id is assigned dynamically you cannot use a static translate filter or something like that.
It depends on your api but one possible approach is to get the corresponding user_id via http requests. For that purpose you could use a community plugin. For example logstash-filter-rest with a config like this:
filter {
rest {
url => "http://yourserver/getUserBySessionId/"
sprintf => true
method => "post"
params => {
"session_id" => "%{session_id}"
}
response_key => "user_id"
}
}
What method would you use to associate tracking information in Google Analytics with a particular named user?
I want to be able to do custom reports, and ultimately drill down on usage by user.
EDIT
I was thinking that perhaps the EventTracking API would be able to help somehow.
Also, referring to this documentation.
You could add the user's username as a tracking/segmentation) variable...
pageTracker._setVar(username);
You can only use one _setVar per page, though...
http://www.google.com/support/analytics/bin/answer.py?answer=57045
http://groups.google.com/group/analytics-help-basics/browse_thread/thread/07e29dc610050971
Since Google Analytics isn't aware of users who are logged into your site you'd have to do that sort of tracking within your site's software itself. If there isn't some sort of plugin or extension out there already you'll probably have to write one yourself that keeps track of what your users do when their logged in.
I think you want Google Analytics - Custom Variables. You can set five variables per page, and there is support for variables you set persisting over session and cookie (aka "visitor") lifetime. Take note of the rules for overwriting previous values based upon slot and scope; the documentation explains this with some examples. You should probably include something in a click-wrapped privacy policy about tracking individual users this way; it's somewhat invasive, depending on the purpose of your website.
_gaq.push(['_setCustomVar',
1, // Slot number: [1-5], inclusive. Required.
'Username', // Custom variable name. Required.
username, // Custom variable value. Required.
2 // Scope:
// 1 = visitor/cookie-level, 2 = session-level, 3 = page-level.
// Optional, default=3.
]);
http://www.highlyrelevant.com/2011/03/25/how-to-add-edit-google-analytics-users-to-your-account/
This post was really helpful for me and my team. Not only does it show how to add users, but it also tells you how to edit existing users that aren't setup correctly.
Thanks!
Phil