How to list all existing users using Riak admin-shell? - riak

In Riak, how do I retrieve a list of currently existing users? I can't seem to find it anywhere on Stack Overflow.

This info can be accessed at any time:
riak-admin security print-users
Example output, assuming user named riakuser with an assigned password:
+----------+--------+----------------------+------------------------------+
| username | groups | password | options |
+----------+--------+----------------------+------------------------------+
| riakuser | |983e8ae1421574b8733824| [] |
+----------+--------+----------------------+------------------------------+
Note: All passwords are displayed in encrypted form in console output.
If you’d like to see which permissions have been assigned to riakuser, you would need to use the print-grants command.
The security print-user (singular) command can be used with a name as argument to see the same information as above, except for only that user.
See basho/docs Security Basics for more information on user management.

Related

Firebase/Firestore : How to add an "Auth" user to a "organization" collection?

I have a Firestore structure with an "organizations" collection and a "users" collection.
When a user creates an account via Auth, I'd like to create a new "Organization" and add him to this organization. That means having a "Create" right.
The problem is that, by doing so, the user can create multiple Organizations and be in them.
The other issue I'm facing is regarding the changes. When that user will change their information (name, email, etc), it will also update their line at the "users" collection, but that also means they will be able to change the "organization" reference and point it to another one, which is bad.
So I wonder what is the proper way to do so, and/or if I'm doing it wrong.
That technique is called denormalization and it's a common practice when it comes to top NoSQL databases.
As I understand from your question, you want to add users to be part of the organization. In that case, there is no need to duplicate the data. I would use a structure that looks like this:
Firestore-root
|
---- users (collection)
| |
| --- $uid (document)
| |
| --- organizations: [$orgId, $orgId, $orgId] (array)
|
---- organizations (collection)
|
--- $orgId (document)
|
--- users: [$uid, $uid, $uid] (array)
In which "organizations" is an array that holds organizations IDs, and "users" is an array that holds user IDs.
Since we usually are structuring a Firestore database according to the queries that we want to perform, the above schema will help you query all the organizations a user is a part of or all users that are a part of an organization. This means that if you want to display user data, you have to perform a new Firestore database call.

Connect two random users from Database

I’m trying to create an app where I need to match two random users from my Firebase Database. The problem I have is that I‘m not sure how to connect every user of the database to random pairs:
As far as I thought the user might press a button to signal that he‘s ready, so a child of his UID like 'searching' turns from false to true. By receiving a DataSnapshot the user can see if another user is searching too. Then I thought of turning the 'searching' state to false for both users and create a new UniqueID to connect them.
But like that it‘s thought pretty short, I think and would cause some problems. Can anyone give me a hint on how to organize that searching process?
Actually using a special node like searching and setting it to true and false will be a good idea.
You can use orderByChild() to order all the users with searching node set to true and get the uid of any of those users.
To make the process random you could make a call to users, take the ids given back to you, and pick one at random with a basic random number.
If after making a call to users you have 10 user ids in an array you would want to get a random number between 0-9 and then make a call to firebase with the userId.
I don't believe Firebase has any built in code for this. So this would be the best thing you can do to achieve this feature in your app.
To give a basic idea, your database structure should look something like this:
--rootNode
|
|
-- uid1
| |
| - searching
| - other Fields
|
-- uid2
.
.
.

Firebase set roles to users

I have a situation in Firebase where users have roles. According some profile already defined in another "schema" users can delete, update, create, delete and update, etc, etc... Many combinations are made.
Ex.:
Users/:
user_1:
create: "ok"
delete: "no"
update: "ok"
user_2:
create: "no"
... etc ...
How manage this in firebase once ".write' permission do not accept dynamic condition? I found Bolt that have some alias (create(), update(), delete()) to that however, you have only create OR update OR delete. Once one is defined you cannot change.
Thanks
Okay, so I'm going to assume that your data is structured something like below. This answer is my own subjective approach to how I would dynamically manage users accessing different parts of the DB.
NOTE::the chmod that I use stands for READ-WRITE-DELETE, instead of READ-WRITE-EXECUTE (i.e. 6=read+write but not delete, 7=full CRUD privileges). This sample DB is structured in 3 parts, and models a social media app. Also, the default for the "world" (3rd digit would most likely be only authenticated users. This is a very simple example:
root/
|
|-- user/ <-main node that contains profile info
| \uid <-node name - one for each user with sub-nodes containing profile info
| \user
| |-<UID> <-shows who has "user" privileges (1st digit)
| \group
| |-<UID> <-shows who has "group" privileges (1st digit)
| \permissions = 744 <-universal "user" entry rule
|
|-- trending/ <-node that contains global, read only info
| \user <-No one will be here for "trending"
| \group
| \feed-data
| \<POST_UUIDS> <-Data here
| \permissions = 444 <-Everyone can read the global feed
|
|-- messaging/
| \<chat-uuid-number-1>
| \user
| |-<User1>
| |-<User2>
| \group
| \messages node
| \<chat-uuid-number-2>
| \user
| |-<User8>
| |-<User5>
| \messages-node
|
| \permissions = 600 <-Only 2 users can read&send messages in their node
|
|-- chatrooms/ <-each node contains a list of UID, and list of messages
| \<room-uuid-number>
| \user
| |-<Admin1>
| |-<Admin2...>
| \group
| |-<uid1>
| |-<uid2>
| |-<uid3...infinity>
| \permissions = 760 <-Only admins have user privilege, users in chat can send and receive in the chat though
So this is a somewhat denormalized database structure, like JSON databases are apparently supposed to be. Read about this here: https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html Each branch does not hold very much information except exactly what it is concerned with. Now, if you have a unified "inheritance" type structure, then you can use relative directory paths to check relative to the directory that a user is trying to access and isolate the validation rules in one spot- at your root - and then all the children nodes will be covered as long as they all have uniform structure for basic permissions!
So as long as your new data is NEVER going into the root directory or any of the main nodes/directories below it (you can write rules to ensure this also), you use data.parent() to get to the parent of your entry, then call parent() again to get to the main directory (e.g. chatroom), then you check the permissions value for each consecutive number, and match against the list of users/group/world:
".write": "data.parent().parent().child('permissions').val().beginsWith('6') && data.parent().child('users').child($uid).exists"
This (pseudocode?) checks the first digit of the permissions code, and then checks the node's "users" subdir to see if the current user has user privileges for that particular sub-node. Add a conditional OR after this to check and see if there's group writing privileges and the user exists in the group. And so on... all from the root directory! Just make sure you guard against writing under '/' or '//' (write those conditionals first using '&&' so it fails the check before trying to get parent of the root, etc.) and it should work well.
This isn't an absolute structure, but I set mine up to be 'shallow' database all while restricting each entry under a major directory like "messages" to have a permissions code and check for that UID of the user making the DB read/write, and it saved me a ton of pain down the line. Although the last time I used it was about 5 months ago, I'm not sure if things have gotten simpler or simple tools/libraries exist now. Hope this helped!
I found a solution... no ideia if is the best one... however, solve my problem.
In any case, is a little painful to write the conditions.
and then in your firebase rules:
CUD means Create Update Delete. You can use chmod numbers as well (777, 765, etc).
Now, I need to discover how to write the conditions for -ud, --d, etc.
:)

Correct Firebase database layout for a user to user (and group) chat app?

I'm trying to understand the best database structure to store and retrieve user to user conversations using the Firebase database for a chat app (web based).
My current plan is to give each chat its own ID which would be created by combining the unique Firebase IDs of the two chat participants (like UserID1_UserID2), for example: FQ5d0jwLQDcQLryzevBxKrP72Bb2_GSIbxEMi4jOnWhrZaq528KJKDbm8 this chat ID would be stored in the database, and would contain the messages sent between the two participants.
Example layout:
MYAPP
|_______conversations
| |_____UserID1_UserID2
| | |
| | |__OshwYF72Jhd9bUw56W7d
| | | |__name:"Jane"
| | | |__text:"Hello!"
| | |
| | |__KbHy4293dYgVtT9pdoW
| | |__PS8tgw53SnO892Jhweh
| | |__Qufi83bdyg037D7RBif
| | |__Gicuwy8r23ndoijdakr
| |
| |_____UserID5_UserID16
| |_____UserID8_UserID7
| |_____UserID3_UserID8
|
|_______users
Whenever a user signs into the app, they'll see a list of their contacts. When they select one to chat with, I would use some Javascript to combine their, and their selected friend's Firebase ID to generate the chat ID. This chat ID would then be either created in the database (if it's their first time to chat), or it would be used to load previous messages that they have exchanged (if they have chatted before), from the database.
My question is, is this the correct method to use? What issues might I run into if I use this method? For example, would I have problems if I try to implement group conversations (with more than 2 people) in the future?
I'd be really grateful for any help, or examples of the correct database layout logic for a person to person (and group) chat application using Firebase/a no SQL database.
Thank you in advance!
Something that I would like to point out as one of the most important "rules" to consider when creating a NoSQL database is that you must
Structure your data after the view.
This means that the data must be structured in such a way, that when you want to display it on your view (probably your html pages) you do a single read.
So in order to find the best way to structure your database, you must first look at your view. And try to imagine how you would read data (direct reads and queries).
Altought your current structure looks good (for what you're building now), yes, you might have some problems when creating group chats. I would recommend using something like this:
You wil notice that this way, you can actually add more participants to each chat easily. Note that this isn't supposed to be your only node. You would have to create other nodes like users (to store the user details) and messages (store each chat's messages), etc
To help you with that, I recommend watching David East's Firebase Database For SQL Developers.

Meteor permission at field level (not Collection.allow )

Collection.allow provides a way to authorize or not the insert/updated/delete of documents based, for instance, on user role.
However, here, I am looking for a generic solution to allow the read or write of, not a document, but a document's field, based on more precise roles.
Examples:
Allow RoleA to see and edit item's price.
Allow RoleB to only see item's price.
Do not allow RoleC to see/edit item price, the client browser would receive the item with all the fields except the price.
Another way to describe the example is using the following matrix:
+-------------+---------------------+---------------+
| Schema Item | Field 'name' | Field 'price' |
+-------------+---------------------+---------------+
+-------------+---------------------+---------------+
| Read | RoleA, RoleB, RoleC | RoleA, RoleB |
+-------------+---------------------+---------------+
| Write | RoleA, RoleB, RoleC | Role A |
+-------------+---------------------+---------------+
How would you implement that matrix, or what solution would you pick to have a permission system that affects not documents, but fields ?
Note: the question is asked as the application has around 15 document types, and between 10 and 20 user profiles, to avoid to have an insane 'if' complexity.
Regards
I would start with the alanning:roles package. Then for reading I would implement the restrictions in your publish functions using something like this:
Meteor.publish('myPublication', function (group) {
let fields = { name: 1};
if ( !Roles.userIsInRole(this.userId, 'RoleC',group) ) fields.price = 1;
if (Roles.userIsInRole(this.userId, ['RoleA','RoleB','RoleC'], group)) {
return MyPublication.find({},fields);
} else {
this.ready();
}
});
For writing I would probably go with aldeed:simple-schema and enforce the role restrictions in an autoValue function.
I agree, however, that there isn't a generic solution where you create tables of permissions on a role x document x field basis. That would make for an interesting package.

Resources