Embed formated ACL information to JSON in Symfony2 - json

I am using Symfony2 and its ACL security component in my project. I want to use the ACL information in the frontend framework for show/hide elements.
Would it be a terrible idea security wise to attach formated ACL information for current user on current object?
Lets say the user has permission to VIEW and EDIT object, so the JSON data would look like this:
{
"id": 1,
"name": "Product",
"_permissions": ["VIEW", "EDIT"]
}
What security holes this solution can potentially cause?

I don't think there is a security problem. You will agree that it can not be a problem to have the id and type of the object in your data :-). So the only thing we should take a look at are the VIEW and EDIT attributes. These values are not a secret. They are part of the Symfony documentation. So it's only about the information if you have these permissions for that object.
If you return that JSON together with your data I think, the VIEW attribute is actually no additional information as it would not be returned if you would not have the VIEW permission. So the only information you provide here is if the user can edit that object.
If you think about it you will agree that you would provide the same information if you would on server side decide based on permissions if you add an edit link for that object to a html page or not.
So if you do an isGranted("EDIT", $product) to decide if you return that EDIT as part of your JSON I can not see any security hole there.

Related

Azure common alert schema sets the commonPropertie as "null"

Well I will explain all about my case.
Im trying to set up Azure alerts that sends a custom mails, to do so I need a logic app that parse the info about the said alerts.
The problem is, even if I enable the common alert schema, and fill the custom properties field, as you can see in the image.
But what this alert sends to my Logic App in the customProerties field is a Null value, I don't get why.
But more than that, if I disable the common alert schema, the custom properties field will be sent without problems.
I don't understand if common alert schema doesn't allow customProperties, or if Im doing something bad, I need help.
Thanks for read and ask for it if anything of this post is bad explained.
I have just confirmed this issue with Microsoft support.
If I point an Activity Log Alert Rule to an Action Group Webhook with Common Schema enabled then the Custom Properties don't appear in the JSON payload. If I disable the Common Schema then the property does appear in the payload.
If I do the same for a Metric alert or Log Query alert, the Custom Properties do appear at the Webhook endpoint regardless of whether the Common Schema is enabled or not.
Microsoft pointed that the schemas for each type are documented (no custom property on the Activity Log Common Schema) and that this is not a bug. Well... the Alert Rule form does allow to configure the Custom Properties for each type of alert so... ah well, nevermind.
They also said "There are plans to align the behaviour on all alert types including activity logs, although there is no definite ETA though. For now, the best option for you to be able to customize the payloads of activity log alerts is by using logic app as an action group."

How can I tell whether a web service is "Restful" (as it claims to be)?

I am trying to work with a service that its creators describe as "restful"
To make a request to this service I have to post some Json e.g.
{
"#type" : "Something"
"$value" : 1
}
This is posted to a URL similar to this;
https://someSite.com/api/query/execute
No matter what the nature of the request, whether I am retrieving info, adding or updating it I must always use this URL (along with some header values to verify my credentials). The effects of posting to this service are determined by the JSON I send.
Depending on the nature of the call I will receive some JSON very similar to the sample above. This JSON never includes another URL (or part of one). It is always a "data object" i.e. a set of properties and their values. Sometimes I receive an empty response but know that the request has had an effect because I can view those effects through a website provided by the service provider
I have particular issues with ENUM values that I must send because I have no idea of the allowed values (they are always passed as strings)
No documentation has been provided for this service.
I am relatively new to RESTful services and JSON and would like to know whether this is truly a restful service, and if not why not?
Due to my lack of experience in this area I may have omitted some important information that would be required to properly answer this question. I will watch the comments closely and try to provide any additional clarification requested
know whether this is truly a restful service, and if not why not?
It isn't.
One of the main principles of REST is that "things" are identified by URLs. Having a single URL for all interaction with the API violates that principle.

REST-API database-relationships back-referencing

I’m developing a REST-API with NodeJS and Express with a MySQL-backend. The existing database has a lot of 1:n relationships and I’m struggling to find the right URI-scheme for these specific cases.
A simple example:
user {
id
name
}
comment {
id
text
user_id
}
Now, when I try to get the a list of all users, my uri would be: /users
- for one specific user: /user/{id}
- data for one specific user: /user/{id}/name
- for a list of all comments: /comment
- for one specific comment: /comment/{id}
- data for one specific comment: /comment/{id}/text
Now, the part where I’m struggling.
There is a 1:n relationship between user and comment. One user can have multiple comments, one comment belongs to one user. I want to implement something like a ‘back-reference’, so that when I access the data (meaning one specific field) for one specific comment, I can also get the information about the user the comment ‘belongs’ to.
The API doesn't know about these relationships, I'm also not using an ORM, so I have to hard code the information about the relationships somewhere anyway.
I already implemented a route where I can make a request on /comment/{id}/user_id where I redirect the request to /user/{id} with the id the comment belongs to. But this would be the same request for when I just want to get the user id for that comment, not the whole dataset for the user.
I've read a lot about the REST architecture and roy fielding always talks about making the API "browsable" or "explorable". One approach I came upon was adding a reference uri to the linked dataset, in my example that would mean expanding the user_id field to something like this :
user_id {
id:id
ref:/user/id
}
The results I'm getting from the database are much more complex than that and extracting the respective fields and adding this information seems like a bit much to do for this ‘simple’ problem.
I don't know if I'm missing something here, I'm developing this API for a project on which I also write a paper about and I try to follow the rules of the REST architecture as much as I can, but I'm a bit stuck right now.
What about publishing the comments "under" the user resources like this:
/user/{userid}
/user/{userid}/comments/{commentid}
Note, that you don't have to publish "database rows" one-to-one in a REST API. Indeed, this is usually frowned upon by REST people.
Also note, you don't have to publish each attribute of a resource as a resource. The resource /user/{userid} could very well return a complex (json, xml, etc.) representation that includes all the necessary data. Of course there are reasons to do it your way, for example I would make the text of a comment a separate resource if it is available in pdf, text, html, or in other formats which I don't control.
A minor point about Fielding's "browsable" API: What he means is that these resources reference each other through links in the returned data representations. Comments would reference the users (link to user), and users should reference their comments (links to comments). The client should never have to "guess" or "construct" an URI on its own, it should "browse" resources by following links only!

Whats the REST way of showing forms to user

I was reading this Questions regarding REST
What exactly is RESTful programming?
While reading i get that the client is independent of server and client don't need to construct anything.
I want to know that when we are building forms like user registration . Then what is the REST way of doing it.
I mean when i do GET for /user/new then
Does the server has to send the complete FORM in html
Only send fields in JSON and form is constructed by client itself
But then again there will be many complexities, if i just send the fields, then what things like
Hidden fields
Default value for select boxes
what about some logic like this field can'r be greater than 30 etc
REST is, as you're already aware, a way of communicating between a client and a server. However, the issue here is what is being defined as the "client". Personally, I tend to consider that the browser itself is not in itself the client: instead, the client is written in JavaScript, and the browser is merely a conduit to executing it.
Say for the sake of argument that you wish to view the details of user '1414'. The browser would be directed to the following location:
/UserDetails.html#1414
This would load the static file ViewUser.html, containing all the form fields that may be necessary, as well as (via a <script> tag) your JavaScript client. The client would load, look at the URL and make a RESTful call to:
GET /services/Users/1414
which would send back JSON data relating to that user. When the user then hits "save", the client would then make the following call:
PUT /services/Users/1414
to store the data.
In your example, you wanted to know how this would work with a new user. The URL that the browser would be directed to would be:
/UserDetails.html#0
(or #new, or just # - just something to tell the JavaScript that this is a new client. This isn't a RESTful URL so the precise details are irrelevant).
The browser would again load the static file ViewUser.html and your JavaScript client, but this time no GET would be made on the Users service - there is no user to download. In addition, when the user is saved, this time the call would be:
POST /services/Users/
with the service ideally returning a 302 to /services/Users/1541 - the location of the object created. Note that as this is handled in the client not the browser, no actual redirection occurs.
"Forms" for hypermedia APIs could be rendered in a "forms aware" media type like for instance Mason (https://github.com/JornWildt/Mason), Hydra (http://www.markus-lanthaler.com/hydra/) or Sirene (https://github.com/kevinswiber/siren). In Mason (which is my project) you could have a "create user" action like this:
{
"#actions": {
"create-user": {
"type": "json",
"href": "... URL to resource accepting the POST ...",
"method": "POST",
"title": "Create new user",
"schemaUrl": "... Optional URL to JSON schema definition for input ..."
"template": {
"Windows Domain": "acme"
}
}
}
}
The client can GET a resource that include the above action, find it be the name "create-user" and in this way be told which method to use, where to apply it, how the payload should be formated (in this case its JSON as described by an external schema definition) and some default values (the "template" object).
If you need more complex descriptions (like selection lists and validation rules as you mention) then you are on your own and will have to encoded that information in your own data - or use HTML or XForms.
There are multiple ways to do what you want.
You can use GET for /user/new along with a create-form link relation to get a single link. This can in plain HTML or HTML fragment, or a schema description, practically anything you want (the result will be less reusable than the other solutions).
You can use a standard MIME type which supports form descriptions. For example HAL with a form extension or collection+json.
You can use an RDF format, like JSON-LD with a proper vocab like Hydra.

Customizing json rendering for sling's userManager

I am trying to build my application's admin UI using sling's userManager REST interface, but I would like to customize the json rendering. For example, I would like the response of "Get group" to include the members only if the requestor is a member.
I started by adding libs/sling/group/json.esp but I don't understand how I can get hold of the default response and customize it. Even if I had to query and form the json from scratch, where can I find information about APIs available to get this data from JCR/Sling?
I found that I could use ResourceTraversor to dump the resource object in json form but using new Packages.org.apache.sling.servlets.get.impl.helpers.ResourceTraversor(-1, 10000, resource, true) in the esp throws up an error
There are a few things to note here.
First, you should avoid putting your code under the libs directory. Your app code should live under the apps directory. When attempting to resolve a servlet for a URI, Sling will check apps before it checks libs so if you need to completely override functionality delivered with Sling, you would place your code in apps.
Second, what is (probably, depending on how you have things setup) happening when you request http://localhost:8080/system/userManager/group/administrators.tidy.1.json is the request is being handled by Sling's default GET servlet, because it finds no other script or servlet which is applicable. For research purposes it might be worth looking at the code for the default get servlet, org.apache.sling.servlets.get.impl.DefaultGetServlet, to see what it's using to render JSON. If you need to handle the rendering of a user group in a manner different than what the default GET servlet is doing, then you would need to create a servlet which is listening for requests for resources of type sling/group. It would probably be ideal to create a servlet for this purpose and register it with OSGI. http://sling.apache.org/site/servlets.html provides the various properties you would need to set to ensure the servlet resolver finds your servlet. Your servlet then would handle the request and as such would have direct and easy access to the requested resource.
Third, the particular need you specified is that you do not want the group members to render unless the requesting user is a member of the group requested. This is more of an access control issue than a rendering issue. Sling and Jackrabbit, out of the box, make as few assumptions as possible concerning how you might want your application to be setup. That being the case, you need to establish the access controls that are applicable for your particular use case. The wiki post on Access Control in the Jackrabbit wiki ( http://wiki.apache.org/jackrabbit/AccessControl ) goes into this to an extent.
Using directions from Paul Michelotti's answer, I researched further and found a suitable solution to my problem.
Sling accepts request filters (javax.servlet.Filter) through SCR annotations like the one below
#SlingFilter(scope = SlingFilterScope.REQUEST, order = Integer.MIN_VALUE)
Every request is passed down to the filter before it is processed by the servlet. Using the resourceType, I was able to distinguish requests to group.1.json and group/mygroup.1.json. Since the filter also has access to the current user, I was able to decide to deny the request if it did not abide by my security model and return a 404 status code.
Please refer to this page for details on filters. You can also check out the sample project urlfilter for directions on usage.