I know that I can implement an interface when defining an Entity, but I want to be able to treat all implementations of this interface as if they had a shared table, with a common Repository. To better illustrate my problem, here a two examples:
GitHub repository owners
On GitHub both users and organizations can own repositories. Let's imagine there is a User and an Organization entity. They both implement the RepositoryOwner interface that specifies stuff like an array of Repository's as a relation.
Now take a look at GitHub's "Trending developers" page. It treats User's and Organization's equally as if there was a common Repository<RepositoryOwner> that could be used to fetch the data.
Resource sharing site
A site where users can upload different types of resources like images, videos and documents. All of these types have their own Entity with different properties, but all of them implement the Resource interface. On a user's profile page there's a list of all the resources uploaded by this user. A Repository<Resource> would be very helpful again, the type of a resource is determined using typeof and displayed using an icon.
I'm assuming that you intend to share a common table from which you want to derive two more tables? In that case you can define an interface IRepositoryOwner and implement it in a base entity RepositoryOwner. And then extend RepositoryOwner to Organization and User entities.
This would allow you to retrieve an array of RepositoryOwners but repositoryOwner instanceof User would be false. And casting repositoryOwner to User would not be possible. You'd be missing the derived class properties.
Related
This question comes from the perspective of someone who's familiar with CloudKit and is moving to the Realm Mobile Platform.
With CloudKit we have the concept of private, public and shared databases. The private belongs to the user, the public can be seen by every user and the shared database is like a view into a user's private database used to share data between a limited number of users (friends).
Let's say I want to allow two users to collaborate on a project, user A will create the project and invite user B to collaborate, which mechanism would I use with realm to allow this, without completely opening up user A's private realm to user B (only the records specific to the project user A wants to share)?
Right now Realm permissions are granular to the database (Realm) level. There's no way to grant specific permissions that only apply to a subset of the data in a given Realm.
A high priority item on our roadmap are features to support working with partial copies of synced Realms. In the meantime, we'd recommend creating multiple private Realms for a given user to represent each subset of permissions. For example, you may have a truly private Realm for a given user, and one or more Realms for that user that represent data which can be shared with other users. In your specific case, you might want to create a Realm per project, rather than a Realm for all projects owned by a user.
As for actually granting permissions, you may create a RLMSyncPermissionValue object and pass it into the appropriate API on RLMSyncUser (e.g. -[RLMSyncUser applyPermission:callback:] or -[RLMSyncUser revokePermission:callback:]) to grant or revoke a permission. This requires knowing the identity of the user, which is generated by the Realm Object Server when the user is created.
You may also create a RLMSyncPermissionOffer object to represent an invitation by your user to another user to access their Realm (i.e. project). Such an object generates a string which can be passed to another user through a different channel (e.g. e-mail) and used to create a RLMSyncPermissionOfferResponse object to accept that offer.
Finally, in addition to the partial replication support I mentioned earlier we also have a few other items in the pipeline to make collaborative use of synced Realms easier; we hope to have more to share very soon.
I'm creating a jhipster application and I want to let my user access only to the entities that he created, for example in my case I just want to have for each user a special view of the entities product that he created and not for all the products created by other user.
Thank you in advance,
Waiting for your help ...
JHipster does not provide that type of filtering, you'd have to implement it yourself. Out of the box, the only thing you can do is play with the security roles, both in the front-end and the back-end (as pointed out by #gaël-marziou).
In the front, using authorities in the state declaration (entity.js file). In the back, using #Secured in the controllers (EntityResource.java).
In order to the type of filtering you need, you have to create new attributes in your entities to store the user that he/she created, and then create new methods in your repository to do proper queries.
When it comes down to good RESTfull setup, what is the best practice for providing results that pertain to the owner as the requestor and results that pertain to a user wanting data owned by another user.
I have read that a resource should have max 2 base URLs so how to handle say,
Get all items for authenticated user
Get a single item for Authenticated user
Get all items for a particular user
Get a single item for a particular user
Although your question is a bit unclear, it seems to me you might mix up "Resources" as in HTTP resources, and Model objects or database rows.
The two do not necessarily have a 1-to-1 relationship, or even 1-to-2 relationship as you seem to imply. You can expose a database row in multiple "forms" as resources, there is no limitation how many times you can aggregate, transform or publish the same information, as long as those are all semantically different things.
So, back to your problem. You can publish resources pertaining to the authenticated user, and just users independently which might also contain the current user. With an URI structure for example like this:
/currentuser
/user/1
/user/2 <- might be the same as /currentuser
/user/3
...
There also could be a list of users recently logged in:
/recentuser/444
/recentuser/445 <- might be again /currentuser
...
That would be a third reference on the same user, but it is ok, because all of those have a different meaning, might even have different representations to offer (one might offer more information than others).
I would like to implement facebook - like news feed for my website, with social functionalities, such as share, like, comment and post and I want to connect it to already created users (nice to have it connected with Azure Active Directory).
Is there any ready solution for this problem?
Thanks in advance!
I don't know of anything specific, and StackOverflow is not the place for generalized library recommendations. However, it should be trivial enough to implement yourself. Activity streams are composed of four main components:
Actor
Verb
Object
Target
For example: "John (actor) shared (verb) a photo (object) with Mary (target)."
Just create an entity that can track these four aspects, and then add a record describing the action each time something happens. By making certain parts foreign keys (actor/target could be foreign keys to your user table), you can then pull actions specifically related to a particular user or other object in your system.
I am creating a Grails website where users will have access to the resources they create. Till here everything is clear to me. I define ROLE_USER and lock down my controllers and actions using the Config.groovy file.
The issue I am facing is that I have requirement to support group of users such that some resources created by a user can be edited/updated/deleted by other users of the same group. How do I associate a user with a "group" in spring security, what is the design/library I should use here?
What you will need to do is to have your users' roles (the authorizations) come from the database. Once that is the case, you can then easily adjust the roles a user (or set of users) has and create/remove them on the fly. The docs have some pretty good info on how to get the roles to come from the database, so I won't go any more into that here.
Once the dynamic roles are in place, however, you still need to be able to connect roles to the objects that are created. There are essentially two ways you can go about doing this:
Access Control Lists
Custom logic
Depending on the granularity you need and the flexibility you want, one option may be more appealing than another.
Access Control Lists essentially allow you to have a permission mapping between each user and each entity instance. As you can imagine, it's a fair bit of overhead and can perform poorly if you have a large number of entities and users.
Putting together your own logic, on the other hand, is much more flexible because you can set up your own scheme to connect entity instances or entity classes to users and their roles.
I dont think that spring-security provides such functionality out of the box so you will have to do that manually.
For each domain class that you this kind of functionality, store the user name of current logged in user
def authenticateService
def user = authenticateService.principal()
entity.setUser(user?.getUsername())
Then in the update/delete method of the contoller you should check if the role of the current logged in user matches
the role of the user that created the entity. If you have a match you should proceed with the update/delete otherwise throw an exception
/redirect the user to an error page
As role you can use the spring security roles or you can create a property on the user object you have created