I have a User that wants to see his online profile, in a site where he previously has registered at. I am in charge of making a Dataflow Diagram out of this situation. I know for sure that the System will return a Profile. That is why I put an arrow from System to User.
How can I express that the User is requesting his profile to the System? I can't think of a way of expressing that in a DFD. I guess it's maybe because you are only supposed to show data flow in a DFD and not actions/requests? Should I completly erase the arrow that goes from User to System(?See his profile?) ?
Context Diagram (Level 0 Dataflow Diagram)
Level 1 Dataflow Diagram
Thanks
No hard and fast answer to this. It's possible to argue against including it (could be considered a control flow, not a dataflow). However, assuming purpose of DFD is for human understanding (i.e. it's a picture to look at) go with what makes most sense to your audience.
If I were drawing it, I'd include the input flow on both L0 & L1 (probably named View Profile rather than Check his profile - I prefer imperative statements). It's both the event that triggers action, and will also likely carry data to identify the user.
I wouldn't however include the flow marked ??? on the L1 diagram. Reason: you're pulling data from a datastore so the query is implicit.
hth.
Related
I have a question about tracking activity and where it belongs.
With a lot of my domain commands, you also might want to track the activity and modifications made by users to a particular context or object.
For example:
lets say we have a items domain/context where we can create and edit items. Users are going to make requests to the api to do this. We might want to track who created an item and an modifications made to it.
In a typical CRUD model, you'd probably find the created by field in the domain object/table
Something doesn't feel right when using DDD to have the activity in the domain object. The activity log feels like a general service that would cross many boundaries? Is it right to have the activity log of who changed what in the domain object. It would feel quite clean and focused without it. The activity logging seems specific to the applications case, not the domain?
So:
Should the activity tracking be in the domain object?
If it shouldn't how do you go about handling this in one command/request. I keep hearing people saying about you should only touch 1 boundary in a command/request.
I would think of this activity log as any other piece of data. You would put it together with the business logic around it. Why do you need this information in the first place? Is your items context going to implement business logic that needs the activity log? If not, then I'd say it doesn't belong in that context.
If what you are trying to achieve with this log is some data analysis that needs the activity from several contexts, then I would say publish events from your business operations (every time a user does something with one of the contexts) and have your activity tracking context listen to them and store the activity in a way that serves this purpose.
If, instead, your items context needs to apply some sort of logic, based on the past activity, then keep it in that context in a format that allows you to implement this business logic.
It's also possible that you actually need both. Some context might just publish the events and not store the activity, while others will publish the events and also track the activity for their own internal needs.
I was doing some first steps with gundb and it looks nice. But I'm having trouble to come up with a solution I would need for an application I'm planning.
It is actually a pretty common use case, there should be a group of users that are allowed to write posts, but all users should be able to read them.
In the documentation there is written a lot about how to heandle read access, but I couldn't find anything about how to handle write access to some data.
Is there a code example somewhere for this? And how does gun handle write permissions in general (some documentation / explanation)?
#gwildu restricted write access with public read is currently easier/beta in SEA (Security, Encryption, Authorization - GUN's permissions framework) than doing private read access (although this is perfectly possible already directly using SEA's lower level utility API, docs here). Although we're working on improving ease-of-use, abstractions/API, and other for it.
So the first thing you need to know is summarized in this fairly short guide:
https://gun.eco/docs/Auth
That will cover introducing you to GUN's cryptographic concepts as well as how easy it is to create and login into a user.
The next step, you'll see is that writes to the gun.user() object have the same API as gun but automatically defaults it to be write-restricted (to that user, nobody else can tamper with it) and public-read.
So as of today (2018/6/27) you can use this to achieve what you want. All you need to know is the which users you want a write to come from, and then subscribe to it. With a bit of extra code, you can do this today (hit up the https://gitter.im/amark/gun for help!)
In the future, you can expect an API like this:
user.get('thingOthers').get('canWriteTo').trust(alice)
Now when you subscribe to the data, you'd get back realtime updates from those who you have allowed to write to the data:
user.get('thingOthers').get('canWriteTo').on(data => console.log(data))
Depending upon your use case (and possibly a slightly different API, but hopefully not), this would also work for others reading your data.
For instance, assume you were user Bob (so Bob added Alice as write-access), and some 3rd party viewer, say Carl wants to read Bob's data, if they were to:
bob.get('thingsOthers').get('canWriteTo').on(data => console.log(data))
It would subscribe to realtime updates from only those allowed to write to the data.
Why is there a difference here, what is the nuance you should be aware of?
A) A person may want to trust what somebody else says but NOT trust somebody else to speak on their behalf.
B) If you do trust somebody to speak on your behalf, viewers (like Carl) now must trust an authorizer (Bob) that Alice is permitted to say something. This could be come dangerously centralized!!! (From a trust/permission model, even if the algorithms are P2P/decentralized underneath, which GUN is.)
So while (A) may be a little bit more complicated nuance to understand or manage, it may be the better route. (B) is a little bit easier to think about, but could lead to centralized authority (as in, all Carls in the world just trust Bob to make decisions for them, when it would be better if Carls [using (A)] to decide who they think should have authority.)
So for instance, Bob added Alice as write-access, but Carl could too! That way if Bob and Carl ever disagree on who should have write access, they don't have to trust each other! They would both see what they allow, but not what the other allows.
Obviously, for a lot of applications, it makes sense for everybody to be "on the same page" and have all Carls' just trust Bob as determining who can write data. So (B) is still a good option, just know the implications, and know there are alternative models for trust!
I've created a solution where I created an authorization object which controls what can a user handle or watch in the program. This authorization object is defined with 3 elements:
Process
Activity
Material group
Through transaction 'PFCG' the BC creates the profiles according the requests that users make to have permission to some module of the program. For example, a user or a group of users will access to process 'A1' (Data update), activity '01' (Aproval) and material group 'A0A00001'. This means that these users could only aprove for process 'A1' the data for material group 'A0A00001'.
My problem here is that managers of the areas have told me that they feel uncomfortable making requests to the BC for permissions because they think that they should manage those profiles, and if they want to change those permissions they would like to have the control of them directly instead of making requests.
This is a situation where I don't know what to do, I have thought that I would make Z tables and a Z program to emulate those permissions exactly as they are handled now with transaction 'PFCG' but I feel like I'm reinventing the wheel.
Another thing that I have thought is to create a Z program that would be a layer of transaction 'PFCG' to automate the profiles for this authorization objects but in this case I don't know where to start because I would have to investigate if is there a BAPI for creating profiles and how to manage all the issues related with this management.
The other thing is leave it like that and do nothing, but sincerely I don't know what to do.
Do you have any suggestion on this issue? What can be done in this situation?
I am working on one chatroom [all to all] application in Elixir using OTP Genserver and getting messages from js client as user gets registered with their names as first phase. Now, just bit not sure what would be the best approach to store these names at my elixir server somehow and send regular updates to client with list of users online or database storage. Please suggest the best approach.
I agree with bitwalker that ETS is a good fit.
Here's a short summary of what I did in production. It wasn't a chat server, but a server push with a couple of thousand of users connecting via long polling. Pushed data was divided in some 50 categories, and users were able to choose which ones they want. At peak times the server pushed new messages each 2 secs, and processed > 2000 reqs/sec.
Essentially, I kept a gen_server for each user, where I held pending messages and user's configuration (basically a list of selected channels). This was beneficial with long polling, since user's data is decoupled from the user's request, so the data remains while requests are transient. However, I think this approach is also good for permanent connections, such as websockets, since there might still be occasional disconnections, and keeping a more stable user's data gives you a chance of resuming after reconnect.
Obviously, when a request arrives, you need to find the user specific process, and for this, ETS is a good fit, since you don't have a single process bottleneck. Instead of manually working with ETS, I'd recommend using gproc in conjunction with via tuples. Basically, when starting a user's gen_server, you can provide name: {:via, :gproc, {:n, :l, key}} where key is some custom key (arbitrary term) you make based on your internal user's id(:n and :l indicate a unique name on the local node). You can then use that same via tuple when issuing calls/casts, and gen_server will use gproc to find the corresponding process.
Finally, you need to have some timeout/disconnect logic to cleanup user processes. In my case, I simply terminated a user's process if there was no activity from the web layer (no end-user came for data in some time). Gproc will automatically remove entries for terminated process from its internal ETS table. It's probably best to supervise user processes under a temporary strategy.
I realize all of this is still a bit vague, but I hope it makes some sense. Keep in mind that this is not the ultimate pattern (there's no such thing of course), but I think it's a reasonable first attempt.
You may also want to take a look at Phoenix web framework that has an interesting pub-sub facility in form ofTopics. I didn't try this out myself yet, but it seems interesting, and may even simplify some of the stuff I discussed above, or at least help for pushing notifications from chatroom to all users.
Sounds like a good use case for ETS.
A simpler approach might be to use an Agent to store the online users information, but it depends quite a lot on what you need from the storage mechanism you choose.
I'm diving into RBAC while designing new and rather big/complex site.
I'm trying to figure out if to create a task or simply an operation with biz rule.
Now, I've read most if not all existing documentation. The current documentation says that "a task consists of operations". This wiki article says that the different terms are simply naming conventions and the only limitation that exists is structural one - roles must include tasks (or other roles); tasks should include operations (or other tasks) and operations is the atomic term that is not further composed by other entities.
I've also read the relevant sections in the "Agile web dev..." and "Yii cookbook" books - both do not shed further light on this issue (at least as seen through my glasses).
Lets go to my example where I'll present the question. Actually, lets use an example similar to that demonstrated in most of the documentation resources mentioned above: Lets say I have a blog post and I want/need to have its author be able to "update own post". Now, why should this be a task as commonly demonstrated in the documentation resources and not an operation with a biz rule?
I think that the question above reveals the inclear definition of a "task" (in the RBAC context of course).
Please help me distill a better definition for an RBAC task.
EDIT:
I was suggested the following definitions of the mentioned terms that help conceptualize them in a useful way. In short and in its simplest form: operations are the basic building blocks. They are the material developers work with and only them. Developers compose tasks of and on top of operations. Roles are composed of tasks, like a set of tasks. Roles and tasks are what the site administrators should play with - assign and revoke to users but not operations.
That's a nice way to look and grasp those entities (roles, tasks and operations).
Do you have another option to conceptualize differently? Any comments will be appreciated.
TIA!
Boaz.
I'd say the same as you did in your question edit. A task is simply a composition of operations a user can do that have something in common. So you have for example operations oList, oView, oCreate and oUpdate these are the operation developer assigns to controller actions for access control, where the first two are only read- and the second two have write access to data (that's what they have in common). So you now want to combine those to tasks tInspect and tManage which both hold 2 operations, the first one can list and view and the second one can create and update. Optionally you could make tInspect a sub-task of tManage so a user that has tManage can list, view, update and create but normally you just give his role both tasks.
Regarding the classification of role -> task -> operation, they are essentially the same thing, as you can see in the code they are of class CAuthItem. We name them differently mainly from user point of view.
Operations are only used by developers and they represent the finest level of permission.
Tasks are built on top of operations by developers. They represent the basic building units to be used by RBAC administrators.
Roles are built on top of tasks by administrators and may be assigned to users or user groups.
The above is a recommendation, not requirement. In general, administrators can only see tasks and roles, while developers only care about operations and tasks.
Check this out : http://www.yiiframework.com/forum/index.php/topic/2313-rbac-confusion/page_p_16035#entry16035
if there are two user
1)admin
2)user
so we set role updatePost for update page.
and admin is parent of updatePost so admin can update.
user have updateOwnPost permission.updateOwnPost is parent of updatePost with bizrule.so if bizrule satisfy he can update