I am reviewing Piranha CMS and really like the framework.
I am wondering how I can associate permissions to Regions and Media elements.
I was thinking that this may be easily accomplished through a custom extension but would like to know if this is the recommended approach.
What I'd like to do is to restrict rendering of a region if the current user's does not have access to it. I was thinking I may be able to add a group GUID as the permission property of the region extension. If the permission property is an empty GUID then it will render the region otherwise the current user must be a member of the group that the region is associated to.
I would like to do the same for Media elements.
Cheers
John
You could solve both the region & media question with a custom extension, however I'm not really sure I follow why you would need it for the page region.
As regions are merely considered a "part of a page" there's no way to customize security for a single regions, it is set on the complete page.
As media is usually rendered in some context, as a page, there's currently no security setting for uploaded media. This however is a feature that could be added into the core framework as it could make sense for some use-cases.
Best regards
Håkan
Related
I see either link them directly or visual attribute them. Example: say my website provides a recommendation directly to a user based on their submitted interest, do I just make sure "powered by Foursquare" shows underneath?
Any help would be appreciated! I'm new to tech development
These policies are generally more vague on purpose. Rule of thumb: If you're showing any data to users that isn't your own, it should be clear to them where it's coming from. This is done so the data provider gets proper attribution but also can protect yourself against content being displayed on in your app/site.
For Foursquare specifically, it seems like you would need to include a "Powered by Foursquare" icon and optionally provide a link to the venue if the user may need more information about the place.
Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.
I want such a mechanism that will provide different themes depends on different user roles in Liferay.Is there a way that provide me a solution that i can change theme on User roles.
Secondly i want to know that is this is possible programatically or Liferay provides custom supports with this.
any help will be greatly appreciated.
Bad choice
The right way is not to change the theme but to inject something in the page to alter the style.
It's a bad idea to change the theme at runtime depending on the user session. Poor performance due to the invalidated cache every request.
Build a custom portlet and inject it into the theme for every page. Depending on user logic that portlet can inject some javascript to alter css class of html tag.
Is it clear?
Theme is associated with layout (i.e. page). This can be observed in Layout table of liferay. So, even it can be changed using API, but not something that is different at user level, but its associated at page level.
For your requirement, If you have some fixed number of themes, then having different Sites each having one particular theme been applied.
Using Post login hook, you can check for user role and redirect to appropriate site.
Having this approach you can have completely different layout and pages as well depending on user role if you wish you.
We can also use velocity variables such $is_male, $is_female, $time_zone, $language.. to identify user group and can load different CSS file or a parent class in body tag.
Answer might be not useful for Mark who has raised this but future reader might find this useful.
Thanks
A quick api uri design question. We have resources that belong to our clients. These resources can be edited / viewed / deleted by the client who entered them into our system. The resources can be searched by all clients but access is only granted if certain criteria is met (client has level 3 access etc).
Choice 1: include the client who owns the resource in the uri.
client/:clientname/widgets
client/:clientname/widgets/:id
Choice 2: ditch the whole "client/:clientname" since this part of the uri has to be verified and checked against the credentials of the user accessing the information.
/widgets
/widgets:id
We have other resources other than widgets that also belong to clients.
Which way is the more preferred way and why? Cheers.
The only advantage that Choice 1 gives it that it allows you to effectively namespace widgets/whatever by the user that uploaded them. Similar to Github, how different users can have projects with the same name. If Github were to exclude the username, no two users could have a project with the same name. If the widgets are all unique, I would go with option two and you will have a 1:1 mapping from a widget the the user that created it, thus supplying it is just extra work for whoever is calling it.
If you can have the same widget name for different users, use an approach which includes the username. You may not need to actually use the 'client' word in your url though; using a path like '/:clientname/widget/:widgetid' instead.
Note that this is kind of an opinion based question, so you may get different answers. You'll have to weigh the information provided and in the end make your own decision.
I'm a new REST convert and I'm trying to design my first RESTful (hopefully) api and here is my question about addressing resources
Some notes first:
The data described here are 3d render
jobs
A user (graphics company) has multiple projects.
A project has multiple render jobs.
A render job has multiple frames.
There is a hierarchy enforced in the data (1 render job
belongs to one project, to one user)
How's this for naming my resourses...?
https:/api.myrenderjobsite.com/
/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004
OR a shortened address for renders?
/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004
OR should I shorten (even more) the address if possible, omitting the user when not needed...?
/projects/112233/
/renders/889900/
/renders/889900/frames/0004
THANK YOU!
Instead of thinking about your api in terms of URLs, try thinking of it more like pages and links
between those pages.
Consider the following:
Will it be reasonable to create a resource for users? Do you have 10, 20 or 50 users? Or do you have 10,000 users? If it is the latter then obviously creating a single resource that represents all users is probably not going too work to well when you do a GET on it.
Is the list of Users a reasonable root url? i.e. The entry point into your service. Should the list of projects that belong to a GraphicsCompany be a separate resource, or should it just be embedded into the Graphics Company resource? You can ask the same question of each of the 1-to-many relationships that exist. Even if you do decide to merge the list of projects into the GraphicsCompany resource, you may still want a distinct resource to exist simple for the purpose of being able to POST to it in order to create a new project for that company.
Using this approach you should be able get a good idea of most of the resources in your API and how they are connected without having to worry about what your URLs look like. In fact if you do the design right, then any client application you right will not need to know anything about the URLs that you create. The only part of the system that cares what the URL looks like is your server, so that it can dispatch the request to the right controller.
The other significant question you need to ask yourself is what media type are you going to use for these resources. How many different clients will need to access these resources? Are you writing the clients, or is someone else? Should you attempt to reuse an existing standard like XHTML and classes/microformats? Could you squeeze most of the information into Atom? Maybe Atom with some extra namespaces like GDATA does it? Or is this only going to be used internally so you can just create your own media types, like application/vnd.YourCompany.Project+xml, application/vnd.YourCompany.Render+xml, etc.
There are many things to think about when designing a REST api, don't get hung up on what your URLs look like and you should really try to avoid doing "design by URL".
Presuming that you authenticate to the service, I would use the 1st option, but remove the user, particularly if the user is the currently logged in user.
If user actually represents something else (like client), I would include it, but not if it simply designates the currently logged in user. Agree with StaxMan, though, don't worry too much about squeezing the paths, as readability is key in RESTful APIs.
Personally I would not try to squeeze path too much, that is, some amount of redundant information is helpful both to quickly see what resource is, and for future expansion.
Generally users won't be typing paths anyway, so verbosity is not all that bad.