Restrict published data to a public channel - pubnub

I thought I understood what was going on here. But, apparently not. If I set up permissions like this, NO one receives published data.
{
"channels": {
"myChannel": {
"auths": {
"51EF3B88-3245-4CF1-B324-979F8E8A9EEF": {
"r": 1,
"w": 1
},
"F4EA7F64-27E3-4877-A86C-371FF7A9ABF2": {
"r": 1,
"w": 1
}
},
"r": 0, // I thought this would turn OFF published data for the world
"w": 0, // And the above auths would turn ON published data for the given keys
"ttl": 1
}
},
"subscribe_key": "my-sub-key",
"level": "channel"
}
If I set it up like this, EVERYONE gets published data.
{
"channels": {
"myChannel": {
"auths": {
"51EF3B88-3245-4CF1-B324-979F8E8A9EEF": {
"r": 1,
"w": 1
},
"F4EA7F64-27E3-4877-A86C-371FF7A9ABF2": {
"r": 1,
"w": 1
}
},
"r": 1, // this is the difference
"w": 1, // this is the difference
}
},
"subscribe_key": "my-sub-key",
"level": "channel"
}
My test clients are Java. I have one setting an AuthKey to one of the above keys. The other is not setting an auth key. I can share that code if needed.
What am I not getting here?
Edit
Here are a couple code snippets. I am trying to set up a public channel for all users and then a private channel. What I see is clients that do not set a uuid can still see the published data.
The server permission setting code:
pubnub = new Pubnub("myPubKey", "mySubKey", "mySecretKey");
// the public channel
pubnub.pamGrant("myChannel", true, true, ttl, callback);
pubnub.pamGrant("myChannel", "F4EA7F64-27E3-4877-A86C-371FF7A9ABF2", true, true, ttl, callback);
pubnub.pamGrant("myChannel", "51EF3B88-3245-4CF1-B324-979F8E8A9EEF", true, true, ttl, callback);
// the private channels
pubnub.pamGrant("F4EA7F64-27E3-4877-A86C-371FF7A9ABF2", "F4EA7F64-27E3-4877-A86C-371FF7A9ABF2", true, true, ttl, callback);
pubnub.pamGrant("F4EA7F64-27E3-4877-A86C-371FF7A9ABF2", true, true, ttl, callback);
pubnub.pamGrant("51EF3B88-3245-4CF1-B324-979F8E8A9EEF", "51EF3B88-3245-4CF1-B324-979F8E8A9EEF", true, true, ttl, callback);
pubnub.pamGrant("51EF3B88-3245-4CF1-B324-979F8E8A9EEF", true, true, ttl, callback);
Edit 2
Here is my new attempt at granting permissions. This works, based on help from Craig.
pubnub.pamGrant(Common.channelSummaries, Common.AuthKeyApp1, true, true, Common.ttl, callback);
// grant read and write access to AuthKeyApp1 on the channel AuthKeyApp1
pubnub.pamGrant(Common.AuthKeyApp1, Common.AuthKeyApp1, true, true, Common.ttl, callback);
// grant read and write access to serverUUID on the channel AuthKeyApp1
pubnub.pamGrant(Common.AuthKeyApp1, Common.serverUUID, true, true, Common.ttl, callback);
pubnub.pamGrant(Common.channelSummaries, Common.AuthKeyApp2, true, true, Common.ttl, callback);
// grant read and write access to AuthKeyApp1 on the channel AuthKeyApp1
pubnub.pamGrant(Common.AuthKeyApp2, Common.AuthKeyApp2, true, true, Common.ttl, callback);
// grant read and write access to serverUUID on the channel AuthKeyApp1
pubnub.pamGrant(Common.AuthKeyApp2, Common.serverUUID, true, true, Common.ttl, callback);
// grant read and write access to serverUUID on the channel channelNameGameSummaries
pubnub.pamGrant(Common.channelSummaries, Common.serverUUID, true, true, Common.ttl, callback);
// grant read and write access to serverUUID on the channel channelNameGameSummariesPresense
pubnub.pamGrant(Common.channelSummariesPresense, Common.serverUUID, true, true, Common.ttl, callback);
pubnub.pamGrant("", false, false, Common.ttl, callback);
// Set the servers UUID to serverUUID
pubnub.setUUID(Common.serverUUID);
pubnub.setAuthKey(Common.serverUUID);
Thanks,
Scott

Scott,
I know you answered it already but just to make this official, the issue is that you granted at the channel level then granted at the auth-key level. Access Manager grants are like CSS in reverse: the more general rule overrides the more specific. So the auth-key grant is specific to that auth-key and only users that init PubNub using that auth-key have those access rights.
But a channel level grant (no auth-key specified) opens the channel up to all users. No auth-key required. If true/true is granted on a particular channel, then it is like you turned Access Manager off for that one channel.
If you grant access true/true at the subscriber-key level, it is the same as disabling Access Manager completely. This is typically not useful for anything other than programatically disabling/enabling Access Manager (for whatever reason).
To remove a grant from an auth-key, channel or sub-key (in other words, revoke it), you just grant with false/false. So to revoke at the sub-key level. And in our Java SDK there are revoke methods (many SDKs just rely on grant with false/false access.
See details on our docs site: http://www.pubnub.com/docs/java/javase/api/reference.html#_pubnub_access_manager
That should just about wrap up all your questions above. Let me know if I missed anything.

Related

How to allow customers to apply promo code on existing subscription in stripe customer portal?

in stripe customer portal settings I have set "Allow customers to apply promotion codes", but when I open customer portal I can't find anywhere, where I could add promo code.
I can cancel subscription, update payment methods or customer data as I configured in settings, but not promotion code. Is there something special that needs to be done?
In production we are opening that via special BillingPortalSession (stripe api), but I also checked with generated link from stripe it self.
billing portal configuration features looks like this:
"features": {
"customer_update": {
"allowed_updates": [
"email",
"address",
"phone"
],
"enabled": true
},
"invoice_history": {
"enabled": true
},
"payment_method_update": {
"enabled": true
},
"subscription_cancel": {
"cancellation_reason": {
"enabled": true,
"options": [
"too_expensive",
"missing_features",
"switched_service",
"unused",
"other",
"customer_service",
"too_complex"
]
},
"enabled": true,
"mode": "at_period_end",
"proration_behavior": "none"
},
"subscription_pause": {
"enabled": false
},
"subscription_update": {
"default_allowed_updates": [
"price",
"promotion_code"
],
"enabled": true,
"proration_behavior": "create_prorations"
}
If you are using the default portal configuration on your account, make sure to double check that your "Allow customers to apply promotion codes" setting is enabled in your dashboard settings[1].
If you are using the API to define your billing portal configuration, make sure to check that promotion_code is included in your portal's features.subscription_update.default_allowed_updates list[2].
If neither of those seem to work for you, you can get help by going to Stripe's Discord Server[3] or writing in to their support team[4]. If you go to one of those, please make sure to have an example request ID[5] from a time when you created a customer portal session and did not see the behavior that you were expecting.
[1] https://dashboard.stripe.com/test/settings/billing/portal
[2] https://stripe.com/docs/api/customer_portal/configurations/create#create_portal_configuration-features-subscription_update-default_allowed_updates
[3] https://stripe.com/go/developer-chat
[4] https://support.stripe.com/?contact=true
[5] https://stripe.com/docs/api/request_ids

Scope multiple groups in same Azure access review (API)

I'm trying to create an access review using the Microsoft Graph API. I can't figure out how to scope (target) multiple groups in the same access review using the available documentation and samples. This is easily done when creating one in the Azure portal.
My goal is to have one access review that scope two or three Azure AD groups. These groups are granting access to Reader, Contributor and Owner role within a subscription.
Here is a sample code that I used to create an access review that scope one group.
{
"displayName": "Testing",
"descriptionForAdmins": "Testing",
"descriptionForReviewers": "Testing",
"scope": {
"#odata.type": "#microsoft.graph.accessReviewQueryScope",
"query": "/groups/<groupid>/transitiveMembers",
"queryType": "MicrosoftGraph"
},
"reviewers": [
{
"query": "/groups/<groupid>/owners",
"queryType": "MicrosoftGraph"
}
],
"settings": {
"mailNotificationsEnabled": true,
"reminderNotificationsEnabled": true,
"justificationRequiredOnApproval": true,
"defaultDecisionEnabled": false,
"defaultDecision": "None",
"instanceDurationInDays": 3,
"recommendationsEnabled": false,
"recurrence": {
"pattern": {
"type": "weekly",
"interval": 1
},
"range": {
"type": "noEnd",
"startDate": "2022-02-25T12:02:30.667Z"
}
}
}
}
Any ideas?
I will answer my own question.
I see now in the browser when I create an access review with two groups in scope that it actually creates two separate access reviews, one for each group. It seems that it's not possible to create one access review for multiple groups when posting this.

How to assign roles to the users in Azure Active Directory

I am creating a login module for a web portal. For this I have created a create user api which creates the user in Azure Active Directory. Below is how I am doing this (in Python) using the Graph API:
user_data = {
"accountEnabled": True,
"displayName": "john",
"mailNickname": "john",
"userPrincipalName": "john#demo.onmicrosoft.com",
"passwordProfile": {
"forceChangePasswordNextSignIn": False,
"password": <password>
}
}
jdata = json.dumps(user_data)
conn = http.client.HTTPSConnection('graph.microsoft.com')
conn.request("POST", "/v1.0/users", jdata, headers)
response = conn.getresponse()
This creates the user in active directory and I am also able to login fine. To login, I am using Python's adal library:
context = adal.AuthenticationContext(config_data['AUTHORITY_HOST_URL'] + '/' + config_data['TENANT'], validate_authority = config_data["TENANT"] != 'adfs')
email = email_name + "#" + config_data['TenantName']
token = context.acquire_token_with_username_password(config_data['RESOURCE'], email, raw_data['password'], config_data['RIPE_CONNECT_CLIENT_ID'])
I also need to assign roles to the user I am creating. For ex, I have education portal where when account is created, user also selects if he/she is student, teacher, parent. Based on this, I need to assign these roles to the user so that whenever user logs in, portal knows that this user is student so it will show all the relevant information and will not show other data which is not relevant to student. When a teacher will log in, it will show all the data.
How can I apply role based control system to users in azure active directory. I have gone through some of the documentation which Microsoft has provided on it but it looks like RBAC is only for the user to restrict their usage of any virtual machine/web service on Azure itself.
How can I use RBAC in my scenario. Is there any API available which I can use to further assign roles to users. What are the other alternatives for this.
Can anyone please give me some good suggestions? Please help. Thanks
EDIT:
config_data['RESOURCE']: https://graph.microsoft.com
Below is the response I get in token when authenticating users using adal library:
{
'tokenType': 'Bearer',
'expiresIn': 3599,
'expiresOn': '2020-10-26 13:19:56.881597',
'resource': 'https://graph.microsoft.com',
'accessToken': 'eyJ0eXAiOiJKV1QiLCJub25jZSI6IjU0aG03Z1psNmdqZVNmT1lCcF9jeVliTWtobklKVmdlV1Q2dHF2SnR3cTgiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9iYzkwNDExZi03NmI1LTRhYjMtYWZjYS0xM2QxMTI3N2U0NGIvIiwiaWF0IjoxNjAzNjk0Njk3LCJuYmYiOjE2MDM2OTQ2OTcsImV4cCI6MTYwMzY5ODU5NywiYWNjdCI6MCwiYWNyIjoiMSIsImFpbyI6IkFTUUEyLzhSQUFBQVJjSi9xVDNnZGY4M25Oc1dMaGV0Tlh1YTNWTEs3ZFF0NERyUXJQMEZUc009IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJ1c2VyYWNjZXNzIiwiYXBwaWQiOiJjMDFiNjQ4Mi0yODhkLTQ1MzMtOGM5OC1hN2M1ZTgwNjdjYzgiLCJhcHBpZGFjciI6IjAiLCJpZHR5cCI6InVzZXIiLCJpcGFkZHIiOiIxMDMuMTA4LjUuMzQiLCJuYW1lIjoidGVzdHVzZXIiLCJvaWQiOiIxYmM3OTA4NS0yYTFmLTRmYWQtOGRhOC02NDdmNGI0YjI5MjciLCJwbGF0ZiI6IjE0IiwicHVpZCI6IjEwMDMyMDAwQTg5NURGQUQiLCJyaCI6IjAuQVN3QUgwR1F2TFYyczBxdnloUFJFbmZrUzRKa0c4Q05LRE5GakppbnhlZ0dmTWdzQUhFLiIsInNjcCI6IkFjY2Vzc1Jldmlldy5SZWFkLkFsbCBBY2Nlc3NSZXZpZXcuUmVhZFdyaXRlLkFsbCBBY2Nlc3NSZXZpZXcuUmVhZFdyaXRlLk1lbWJlcnNoaXAgQXBwUm9sZUFzc2lnbm1lbnQuUmVhZFdyaXRlLkFsbCBEaXJlY3RvcnkuQWNjZXNzQXNVc2VyLkFsbCBEaXJlY3RvcnkuUmVhZC5BbGwgRGlyZWN0b3J5LlJlYWRXcml0ZS5BbGwgR3JvdXAuUmVhZC5BbGwgR3JvdXAuUmVhZFdyaXRlLkFsbCBNZW1iZXIuUmVhZC5IaWRkZW4gUGVvcGxlLlJlYWQuQWxsIFBvbGljeS5SZWFkLkFsbCBVc2VyLkV4cG9ydC5BbGwgVXNlci5JbnZpdGUuQWxsIFVzZXIuTWFuYWdlSWRlbnRpdGllcy5BbGwgVXNlci5SZWFkIFVzZXIuUmVhZC5BbGwgVXNlci5SZWFkQmFzaWMuQWxsIFVzZXIuUmVhZFdyaXRlIFVzZXIuUmVhZFdyaXRlLkFsbCBVc2VyQWN0aXZpdHkuUmVhZFdyaXRlLkNyZWF0ZWRCeUFwcCBVc2VyQXV0aGVudGljYXRpb25NZXRob2QuUmVhZCBVc2VyQXV0aGVudGljYXRpb25NZXRob2QuUmVhZC5BbGwgVXNlckF1dGhlbnRpY2F0aW9uTWV0aG9kLlJlYWRXcml0ZSBVc2VyQXV0aGVudGljYXRpb25NZXRob2QuUmVhZFdyaXRlLkFsbCBVc2VyVGltZWxpbmVBY3Rpdml0eS5Xcml0ZS5DcmVhdGVkQnlBcHAiLCJzdWIiOiJld1lCcXVQWTRNN2RJazkyaWdQeUdhanlseTlkeFdNd2FxY0YzOHh1MVUwIiwidGVuYW50X3JlZ2lvbl9zY29wZSI6Ik5BIiwidGlkIjoiYmM5MDQxMWYtNzZiNS00YWIzLWFmY2EtMTNkMTEyNzdlNDRiIiwidW5pcXVlX25hbWUiOiJ0ZXN0dXNlckByaXBlZGVtby5pbmZvIiwidXBuIjoidGVzdHVzZXJAcmlwZWRlbW8uaW5mbyIsInV0aSI6IjJGM0pHNW1FMDBXdlR3N2pzN2lDQUEiLCJ2ZXIiOiIxLjAiLCJ3aWRzIjpbImI3OWZiZjRkLTNlZjktNDY4OS04MTQzLTc2YjE5NGU4NTUwOSJdLCJ4bXNfdGNkdCI6MTUyODQ3NjExOX0.qk3t_nZ0q_koA4D1QZNeBm7DLbuYxiCMNn8TC85dyQz1eY1uIZ1jhj7248z0m4CvELtp27KR8-jssiCzkW1RdUgxShscV6jRbmMPcpbR5YZ5iNZOyQxQHDSAafM0s_mJjQAA8JTwxc4yAhcKOU2R5PcVX6zbeCi28weQDs9q6vke7fCN7UPX6MKQNELBopJnQaXrvc5J9UAhvA1-_FfONnjb3zxRqb55hQuAiKpn2pRzyfD_fHViuPD2UauTZ0-1rwLRPtuMWdPl2aZNGrftfgTCeN6kxUlvunta06cdtyN6XnILCCv7mlYecPPwZi4vd5SC0hIYNIaEgciBa1pwYg',
'refreshToken': '0.ASwAH0GQvLV2s0qvyhPREnfkS4JkG8CNKDNFjJinxegGfMgsAHE.AgABAAAAAAB2UyzwtQEKR7-rWbgdcBZIAQDs_wIA9P-wwH63zoGppq4f4Mz_zC7KfHZm8AYjxC3scz2h4HGhhHlmMNHFwj3IxE-EjTu0fgnzW-0YsRe4ELoB-3kD87Ok7NuF91NlLw2jnsVmfBu3WAbpqPDe_dGbJN6jKORHaXnSZFa32CvXht2wfj-VByzqXCBOIA3N6h61zptbSXvw4kRcobMAnftSgrzmIMwvVZIduEfnzkuSphwla_V0UxQhnAioVQUlJP90-5WRoVjLNqrmLQnaTUrY4ppeKL_u12HJZje1T2TmTHqTIfrGOZz_tvEDGsU06D2AbjTrVCfJget6D4UgKtUuo9L_dGS9PFO6OSMHSzAu32tXrB0pgxz9okm-so1ptpcSh1jtbrZATmYG4olBcEmKD_-meVrgQ7r_XH8GseBPXSSw_Bqvr55GDUbm0qGjDc3qUjHnBAeVZOPJVTKaTOK93UoUtv15DXB23UN-8xQjQ6ynjIUfC_mIJVr4m1K_sDjVAqvsvOX_gM0Zc0OwsUvB3-W_fIbr0CO1Rd38s2XfDOwkuqi8GCab6Jao5DC9rMDxekJmrc1efQvexdnijjGoTm__IGFZF2IUR_ARdJxt6UlPVrIpvAJROO5T7YIEpeR-fo6euq6txYDjiw4ImZCZ5E717lbRQsqiqLshV2TZNmf0rqRPesraBqBi8LfvEei7AdYMor5uMZpcnYPx2xKMnEnCrZBj1PkMc-quDhIoWyRNontHmTa2YbrFWGZBf61g2Y6J_P_5qySljS3JZted2A_jVd45ue2aBzcQVjxuXnKn0EEeoeq_dmxEylWxwoZYL_2hBnlNzgGD5gVXf24uL_RJvuIHat68UOSCt6hf4IwVVLGvNobhqPJO5v5YNvHdmP5P1n0KkEQJLzoyZuY',
'oid': '1bc79085-2a1f-4fad-8da8-647f4b4b2927',
'tenantId': 'bc90411f-76b5-4ab3-afca-13d11277e44b',
'userId': 'testuser#demo.info',
'isUserIdDisplayable': True,
'isMRRT': True,
'_clientId': 'c01b6482-288d-4533-8c98-a7c5e8067cc8',
'_authority': 'https://login.microsoftonline.com/bc90411f-76b5-4ab3-afca-13d11277e44b'
}
Response when using client id as resource:
{
'tokenType': 'Bearer',
'expiresIn': 3599,
'expiresOn': '2020-10-26 13:30:30.990330',
'resource': 'c01b6482-288d-4533-8c98-a7c5e8067cc8',
'accessToken': 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJjMDFiNjQ4Mi0yODhkLTQ1MzMtOGM5OC1hN2M1ZTgwNjdjYzgiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9iYzkwNDExZi03NmI1LTRhYjMtYWZjYS0xM2QxMTI3N2U0NGIvIiwiaWF0IjoxNjAzNjk1MzMxLCJuYmYiOjE2MDM2OTUzMzEsImV4cCI6MTYwMzY5OTIzMSwiYWNyIjoiMSIsImFpbyI6IkUyUmdZTWllNDd1WE15NzlzZXVzTTVjRWZwemJiN2N4MjNOaGw2YklQZmxKVHJxOURDa0EiLCJhbXIiOlsicHdkIl0sImFwcGlkIjoiYzAxYjY0ODItMjg4ZC00NTMzLThjOTgtYTdjNWU4MDY3Y2M4IiwiYXBwaWRhY3IiOiIwIiwiaXBhZGRyIjoiMTAzLjEwOC41LjM0IiwibmFtZSI6InRlc3R1c2VyIiwib2lkIjoiMWJjNzkwODUtMmExZi00ZmFkLThkYTgtNjQ3ZjRiNGIyOTI3IiwicmgiOiIwLkFTd0FIMEdRdkxWMnMwcXZ5aFBSRW5ma1M0SmtHOENOS0RORmpKaW54ZWdHZk1nc0FIRS4iLCJyb2xlcyI6WyJkaXN0cmlidXRvciJdLCJzY3AiOiJBY2Nlc3NSZXZpZXcuUmVhZC5BbGwgQWNjZXNzUmV2aWV3LlJlYWRXcml0ZS5BbGwgQWNjZXNzUmV2aWV3LlJlYWRXcml0ZS5NZW1iZXJzaGlwIEFwcFJvbGVBc3NpZ25tZW50LlJlYWRXcml0ZS5BbGwgRGlyZWN0b3J5LkFjY2Vzc0FzVXNlci5BbGwgRGlyZWN0b3J5LlJlYWQuQWxsIERpcmVjdG9yeS5SZWFkV3JpdGUuQWxsIEdyb3VwLlJlYWQuQWxsIEdyb3VwLlJlYWRXcml0ZS5BbGwgTWVtYmVyLlJlYWQuSGlkZGVuIFBlb3BsZS5SZWFkLkFsbCBQb2xpY3kuUmVhZC5BbGwgVXNlci5FeHBvcnQuQWxsIFVzZXIuSW52aXRlLkFsbCBVc2VyLk1hbmFnZUlkZW50aXRpZXMuQWxsIFVzZXIuUmVhZCBVc2VyLlJlYWQuQWxsIFVzZXIuUmVhZEJhc2ljLkFsbCBVc2VyLlJlYWRXcml0ZSBVc2VyLlJlYWRXcml0ZS5BbGwgVXNlckFjdGl2aXR5LlJlYWRXcml0ZS5DcmVhdGVkQnlBcHAgVXNlckF1dGhlbnRpY2F0aW9uTWV0aG9kLlJlYWQgVXNlckF1dGhlbnRpY2F0aW9uTWV0aG9kLlJlYWQuQWxsIFVzZXJBdXRoZW50aWNhdGlvbk1ldGhvZC5SZWFkV3JpdGUgVXNlckF1dGhlbnRpY2F0aW9uTWV0aG9kLlJlYWRXcml0ZS5BbGwgVXNlclRpbWVsaW5lQWN0aXZpdHkuV3JpdGUuQ3JlYXRlZEJ5QXBwIiwic3ViIjoiXy01cmU1QWY0bjlsdFNETjdQaW5zOFN0QkZSTlR4QUxNaHZLM2QxZi1rNCIsInRpZCI6ImJjOTA0MTFmLTc2YjUtNGFiMy1hZmNhLTEzZDExMjc3ZTQ0YiIsInVuaXF1ZV9uYW1lIjoidGVzdHVzZXJAcmlwZWRlbW8uaW5mbyIsInVwbiI6InRlc3R1c2VyQHJpcGVkZW1vLmluZm8iLCJ1dGkiOiJsNUNBb2dlQm5VV0pzQnktVlBQTkFBIiwidmVyIjoiMS4wIn0.BkjC5-glOieUjsx3QoRs0LuWUbKlX__G9EIDHL3Uxmc1NnTFsAPgi1NdtZuimiP9r6Th976XaHzub_Z6cq_yzRVzQNEon41GGI_mrc3ejjCJnRjgxSTOhQlqiW99E58x6PATPzB2rjwpNj_BOkkAR8qWul-nUxYf071h0RLNqftUigLL85LpkLFSWgBmqp1o7m84Y5lmxPNBsMYoNw7z94lDlR79j-SjwbxhvFO-zaR2qXMw4U2yWHmjxhYx-VJ1goC_esgasutI5PUCndYewzH9pnG9uNTwDFaLpJS_FudQrPSKvr2mVFGqwpuEIfmbybj-Vd2ETPCIu8kZ-b__3g',
'refreshToken': '0.ASwAH0GQvLV2s0qvyhPREnfkS4JkG8CNKDNFjJinxegGfMgsAHE.AgABAAAAAAB2UyzwtQEKR7-rWbgdcBZIAQDs_wIA9P8SUM1Gw4jhn-3gCk4lIUZOSxhqfoeqN6nY7DXdcjtUqsWRbzeB09CdUPwJqkwr42WqsFgQhxRc3NMxt_ZSwut2ZvrapmKCTjXzp3mXzzk3PQulqUQCa0eIgtNhrmjQoQ57L-TkprJnzIrTh2mYQMWDsSJB82jva-5EPi0dmuqvwfmBuWAjJqh1RinAmBZOtl4B5GUqTDvblJMINqV6nNJRESGU51alKLyailCumYDzWlN-ljEdY3O6Y53EwvQBfLbKIckCChXs__Tn0q4UDfmiJpVPdG1K452Jm2IhgCYsp8Uy-pPd2l1ZNObH9Vr5cadkSoAJP9v4I4g7BGokV9J9GiysR7mENhxh_oe3Yao7Mhosmid7Nveplv3BkZxbmilWp_1-11tUrGWEIjz6O1j0i9_0o6UW54SYA5Wj4hFXQ6yQX0x2QBTj7xGJBzsiJ4F3gxuZ_wCZUqyqwkxvqAg8SkK1QUpPQpOlMrfoE-db5jJ4sL1WcQ71ZSD3cfJgLRtajCPIJsutQ-It8FE6rG9Qj8k_srKB6oSKQL62J_X7bUVGLdZRjDVNhWaowam_oz4oNm7z1YELAepOJvpV__PEETAFxpl_zl2WnizKAYsSDMg8U1NZJ11Ihvyh3B_yYUKjPA46iqcWgp0WeUc93L-ZYgIdFy3j1Ie3N7p-hYXCxSdMs0UUnQUcUwgbXnwCfPEwcDdQH0WqwKBAILRml0rR-PAcSY6hUV5g51mQ3mHpfGvTtkIbDEMj2LmwGR872-JOB4gxGn4wv48AuxOrtu-GydcwucY_ev9bKs72XdwXC0vi2KGoVqv5ElJdAqjquf2doxaegCAwFe4APYeQ-AdkyR30CpuJedmp5YBESNTNB4yljreHErk9UXKkCYcCQnk',
'oid': '1bc79085-2a1f-4fad-8da8-647f4b4b2927',
'tenantId': 'bc90411f-76b5-4ab3-afca-13d11277e44b',
'userId': 'testuser#demo.info',
'isUserIdDisplayable': True,
'isMRRT': True,
'_clientId': 'c01b6482-288d-4533-8c98-a7c5e8067cc8',
'_authority': 'https://login.microsoftonline.com/bc90411f-76b5-4ab3-afca-13d11277e44b'
}
I think what you are looking for is app roles and appRoleAssignments: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-approleassignments?view=graph-rest-1.0&tabs=http.
You can define user roles in your app registration manifest, and then assign them through API calls to the endpoint linked above, or through the Azure AD management UI (Enterprise applications -> your app -> Users and groups).
Documentation for app roles: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
Example defined role from the above docs:
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "Writer",
"id": "d1c2ade8-98f8-45fd-aa4a-6d06b947c66f",
"isEnabled": true,
"description": "Writers Have the ability to create tasks.",
"value": "Writer"
}
],

MongoDB query that contain at least one of filters specified in an object

I have a collection in MongoDB that is structured like this:
"5d33488672886334cd21904xx": {
"ownerId": "5d333551k99951924fb3208",
"createdAt": 1582456098,
....phone
....email
....etc
"mainActivities": {
"dogWalking": true
},
"secActivities": {
"washing": true,
"houseSitting": true,
"dogSitting": true,
"training": true,
"trainingEquipment": true,
"selectionAdvice": true,
"institutionsBusinesses": true
}
}
"5d33488672886334cd21904xx": {
"ownerId": "5d333d344d46ed924fb3208",
"createdAt": 99999995,
....phone
....email
....etc
"mainActivities": {
"dogWalking": true
},
"secActivities": {
"washing": false,
"houseSitting": false,
"dogSitting": false,
"training": true,
"trainingEquipment": false,
"selectionAdvice": true,
"institutionsBusinesses": true
}
}
i am sending filters from the front end like so :
{
"filters": {
"mainActivities": {
"dogWalking": true
},
"secActivities": {
"washing": false,
"houseSitting": true,
"dogSitting": true,
"training": true,
"trainingEquipment": true,
"selectionAdvice": false,
"institutionsBusinesses": true
}
}
}
i want to get all the documents that answer the filters and not EXACT match .
Example:
if i am a dog walker service named "Xdog" , who give all the 6/6 activities (secActivities)
in the front end , when user select 2/6 filters i miss this "Xdog" service.
i get to a function who return only the document that specify EXACT match and its not good because
i am missing the services who actually answer this 2/6 filters..
right now i am sending and spreading the "filterBy" variable into the find() function .
Any suggestion would be great i am weak in Databases commands.
Sorry for my poor English!
The way to do partial match is with $or, but I don't think that will do what you actually want.
The example query you showed above is looking for dog walking services that do not provide washing or selectionAdvice services. Your description suggests that you do not want to consider these 2 services because the user did not specify them. In that case, leave these 2 out of the query entirely, using the user selections to add only the relevant fields, like:
.find({
"mainActivities": {
"dogWalking": true
},
"secActivities": {
"houseSitting": true,
"dogSitting": true,
"training": true,
"trainingEquipment": true,
"institutionsBusinesses": true
}
}
If the filters object is already built, you would need to remove the properties that are false. See How do I remove a property from a JavaScript object?

Firebase security rules protect list and public object

I have list of servers which has public access only if you have the key value.
Basically if user has object key, then he can retrive complete child object. but he should not be allowed to access list of objects.
Example of the object
{
"servers": { // list of server
// list should not be access directly - no anonymous access
"key1": { // this object can be access anonymously, if user knows the key
"name": "linux"
//...
},
"key2": {
"name": "ubuntu"
}
}
}
How can I make such security rule in firebase for above object?
Simple:
{
"rules": {
".read": false,
"servers": {
"$serverid": {
".read": true
}
}
}
}
Since the root is not readable, /servers is also not readable and only once you have a /servers/$serverid does the read action become valid.
This and many similar topics are covered in the Firebase guide on Security & Rules.

Resources