Check security in nested entities POST / PUT - symfony

Using Api Platform 2.5 / SF 4.4, I have some entities people can POST / PUT with their nested relations.
For example, I can post a Customer with:
POST /api/customers
{
"lastname": "Doe",
"firstname" : "John",
"addresses": [
{
"#type": "ContactAddress",
"name": "My address",
"address": "Somewhere not so far",
},
{
"#type": "ContactAddress",
"name": "Address of my offices",
"address": "Somewhere a little more far",
},
]
}
I just tested and my point is that I can POST an existing address:
POST /api/customers
{
"lastname": "Doe",
"firstname" : "John",
"addresses": [
{
"#id": "/apip/addresses/3",
"#type": "ContactAddress",
"name": "My address",
"address": "Somewhere not so far",
},
]
}
It will remove the link between the Address identified by ID = 3 and its previous Customer and set to the new customer. I face the same issue with a PUT.
Using a voter on the post_denormalize makes the nested relation already related to the new Customer, I can't access the previous relation of the Address.
Does anyone faced the same problem? From now, the easiest point I found is to get the Address entity from Doctrine, but it's ugly.

Related

JSON API automatic reverse links

Is it a violation of the JSON-API spec to allow reverse relationships to be created automatically?
I need to create resources that, when I link A to B in a relationship, automatically links B to A. In this way I can traverse A to find all of its Bs and can find the parent A from a B. However, I don't want to POST/PATCH to 2 relationships to get this right. I want to establish the relationship once.
Now I know that it is an implementation detail as to how the server maintains link/references as well as how the behaviour is established but I want to build the API in such a way that it doesn't violate the spec.
Assuming I have resources Books and Authors. Books have Authors and Authors have Books. The question is, once I relate an Author to a Book, I need the reverse relationship to be created as well. Is it a violation of the spec in any way to assume that this reverse relationship can be automatically created by simply doing one POST to the Books resource's relationship?
By way of example, starting with the book.
{
"data": {
"type": "books", "id": 123, "attributes": ...,
"links": { "self": "/books/123" },
"relationships": {
"self": "/books/123/relationships/authors",
"related": "/books/123/authors"
}
}
}
And the author
{
"data": {
"type": "authors", "id": 456, "attributes": ...,
"links": { "self": "/authors/456" },
"relationships": {
"self": "/authors/456/relationships/books",
"related": "/authors/456/books"
}
}
}
If I establish the link from a book to an author with a POST to /books/123/relationships/authors
{
"data": [{ "data": "authors", "id": "456" }]
}
Do I need to explicitly do the same for the Author 456 as a POST to /authors/456/relationships/books?
{
"data": [{ "data": "books", "id": "123" }]
}
Or can I let the server build the relationship for me so that I can avoid the second POST and just see the automatic reverse relationship at GET /authors/456/relationships/books?
From the perspective of the spec this is only one relationship represented from two different sides. author and book have a many-to-many relationship. This relationship could be represented in author's resource object as well as book's resource object and of course also via there relationship links. Actually it would be a violation of the spirit of the specification if representations wouldn't match. Having one-sided relationships is another story but in that case one side wouldn't know about the relationships at all (e.g. a book is associated with an author but the author model does not know which books are associated with it).
A post to either one side of that relationship creates the relationship between the two records. It shouldn't matter which side is used to create that relationship and if it's created as part of a creation / update to a resource via it's resource object or via a relationship link representing that relationship. The same applies to deletion of that relationship.
Maybe an example would make that even more clear. Let's assume a book is created with a POST to /books?include=author having these payload:
{
"data": {
"type": "books",
"relationships": {
"author": {
"data": {
"type": "authors",
"id": "1"
}
}
}
}
}
The response may look like this:
{
"data": {
"type": "books",
"id": "7",
"relationships": {
"author": {
"data": { "type": "authors", "id": "1" }
}
}
},
"included": [
{
"type": "authors",
"id": "1",
"relationships": {
"books": {
"data": [
{ "type": "books", "id": "7" }
]
}
}
}
]
}

my city location is not available in IBM Watson api NLU

When I am sending text using Watson api NLU with my city which is located in India. I am getting empty entity. It should be come with data entity location. So how can i solve this problem in watson NLU.
The sentence being sent is:
mba college in bhubaneswar
where Bhubaneswar is the city
So based on your comment sentence of:
"mba college in bhubaneswar"
Putting that into NLU and entity detection fails with:
Error: unsupported text language: unknown, Code: 400
The first issue is that because no language is specified, it tries to guess the language. But there is not enough there to guess (even if it is obvious to you).
The second issue is, even if you specify the language it will not fully recognise. This is because it's not a real sentence, it's a fragment.
NLU doesn't just do a keyword lookup, It tries to understand the parts of speech (POS) and from that, determine what the word means.
So if I give it a real sentence it will work. For example:
I go to an MBA college in Bhubaneswar
I used this sample code:
import json
from watson_developer_cloud import NaturalLanguageUnderstandingV1
from watson_developer_cloud.natural_language_understanding_v1 import Features, EntitiesOptions, RelationsOptions
ctx = {
"url": "https://gateway.watsonplatform.net/natural-language-understanding/api",
"username": "USERNAME",
"password": "PASSWORD"
}
version = '2017-02-27'
text = "I go to an MBA college in Bhubaneswar"
#text = "mba college in bhubaneswar"
nlu = NaturalLanguageUnderstandingV1(version=version, username=ctx.get('username'),password=ctx.get('password'))
entities = EntitiesOptions()
relations = RelationsOptions()
response = nlu.analyze(text=text, features=Features(entities=entities,relations=relations),language='en')
print(json.dumps(response, indent=2))
That gives me the following results.
{
"usage": {
"text_units": 1,
"text_characters": 37,
"features": 2
},
"relations": [
{
"type": "basedIn",
"sentence": "I go to an MBA college in Bhubaneswar",
"score": 0.669215,
"arguments": [
{
"text": "college",
"location": [
15,
22
],
"entities": [
{
"type": "Organization",
"text": "college"
}
]
},
{
"text": "Bhubaneswar",
"location": [
26,
37
],
"entities": [
{
"type": "GeopoliticalEntity",
"text": "Bhubaneswar"
}
]
}
]
}
],
"language": "en",
"entities": [
{
"type": "Location",
"text": "Bhubaneswar",
"relevance": 0.33,
"disambiguation": {
"subtype": [
"IndianCity",
"City"
],
"name": "Bhubaneswar",
"dbpedia_resource": "http://dbpedia.org/resource/Bhubaneswar"
},
"count": 1
}
]
}
If it's a case you are only going to get fragments to scan, then #ReeceMed solution will resolve it for you.
Screenshot of NLU Service responseIf the NLU service does not recognise the city you have entered you can create a custom model using Watson Knowledge Studio which can then be deployed to the NLU Service, giving customised entities and relationships.

In-ValueProvider not Passing Data from ModuleDataSource (Blog App Mod)

I have taken the Blog App, added a Category ContentType as a field in the BlogPost ContentType and built a query to factor Category into the results.
But I am having trouble with the In-ValueProvider. Following the example here the Visual Query Designer seems to be ignoring the incoming value from my ModuleDataSource.
I have double checked the In-Stream name, my Entity names, case, TestParameters, etc. Are there any known bugs in 2sxc 8.44 and up that would cause this issue? What have I missed?
In this case I am using a RelationshipFilter. Relationship is "Category". Filter is "[In:Config:Category]". I can switch out to a [Querystring:Category] and that works fine and runs all my code.
Thanks for reading.
OK I found a workaround.
It turns out that the In-ValueProvider is working but it's struggling with the Category of my BlogPost I think because Category is an entity.
For background I have a BlogPost ContentType, a Category ContentType, and an Articles Home Header ContentType. Articles Home Header sets both the header info for the articles page and the Category entity.
For some reason the RelationshipFilter is having trouble comparing the Category entities between Articles Home Header and BlogPost. I tried the following for my Filter and neither worked:
[In:Config:Category]
[In:Config:Category:Title]
I wonder if this is a case sensitivity issue, a bug, or if I am just misunderstanding the filter syntax.
To work around I created a temp field called TempCategory in my Articles Home Header and used [In:Config:TempCategory] for the filter.
That worked.
For reference here is a snippet from the Query:
{
"Config": [
{
"Title": "Coaching Articles",
"SubTitle": "",
"Image": "/Portals/0/uploadedimages/AcademicPrograms/Christ_College/crosswise-hero.jpg",
"ImageAlt": "Crosswise stained glass",
"Category": [
{
"Id": 2716,
"Title": "Coaching"
}
],
"Id": 3118,
"Modified": "2016-06-21T10:44:21.9Z",
"_2sxcEditInformation": {
"sortOrder": 0
}
}
],
"Paging": [
{
"Title": "Paging Information",
"PageSize": 10,
"PageNumber": 1,
"ItemCount": 0,
"PageCount": 0,
"Id": 0,
"Modified": "0001-01-01T00:00:00Z",
"_2sxcEditInformation": {
"entityId": 0,
"title": "Paging Information"
}
}
],
,
"Default": [
{
"Title": "Protect Your Players and Your Program: An Athletic Leader's Legal Duties",
"UrlKey": "an-athletic-leaders-legal-duties",
"PublishingGroup": null,
"PublicationMoment": "2016-06-15T00:00:00Z",
"Image": "/Portals/0/uploadedimages/AcademicPrograms/Graduate/Coaching/an_athletic_leaders_legal_duty.jpg",
"ImageSquare": false,
"Teaser": "<p>When the clock started on the new year earlier this month, all but one state joined the growing legal effort to protect and prevent concussions and head injuries among America’s young.</p>",
"Body": "<p><strong>When the clock started on the new year earlier this month,</strong> all but one state joined the growing legal effort to protect and prevent concussions and head injuries among America’s young.</p>\n<p>As sports-related injuries and issues continue to dominate the headlines and influence programs throughout the country, laws like “return-to-play” are becoming a sign of the times when it comes to protecting players and athletic programs alike. The world of athletics is experiencing a significant shift in the perception of the roles and responsibilities of coaches, schools and athletic personnel.</p>",
"DesignedContent": [],
"Tags": [
{
"Id": 2576,
"Title": "coaching"
},
{
"Id": 2575,
"Title": "management"
},
{
"Id": 2574,
"Title": "sports"
},
{
"Id": 3035,
"Title": "legal"
}
],
"Author": [
{
"Id": 3030,
"Title": "Shaleek Blackburn"
}
],
"ImageAlt": "Referee holding a red",
"Thumbnail": "",
"ThumbnailAlt": "",
"RelatedArticles": [
{
"Id": 2564,
"Title": "Athletic Personnel's Duty To Warn"
},
{
"Id": 2565,
"Title": "Get A Better Grip On Bullying"
},
{
"Id": 2717,
"Title": "Good Coaching Develops Exceptional Athletes and People"
}
],
"Category": [
{
"Id": 2716,
"Title": "Coaching"
}
],
"ArticleRelationships": null,
"Id": 2513,
"Modified": "2016-06-15T19:32:17.913Z",
"_2sxcEditInformation": {
"entityId": 2513,
"title": "Protect Your Players and Your Program: An Athletic Leader's Legal Duties"
}
}
]
}

JSONAPI - Difference between self and related in a links resource

Why is the self and related references different in the below JSONAPI resource? Aren't they pointing to the same resource? What is the difference between going to /articles/1/relationships/tags and /articles/1/tags?
{
"links": {
"self": "/articles/1/relationships/tags",
"related": "/articles/1/tags"
},
"data": [
{ "type": "tags", "id": "2" },
{ "type": "tags", "id": "3" }
]
}
You can read about that here: https://github.com/json-api/json-api/issues/508.
Basically, with /articles/1/relationships/tags response will be object which represents relationship between articles and tags. The response could be something like this (what you put in your question):
{
"links": {
"self": "/articles/1/relationships/tags",
"related": "/articles/1/tags"
},
"data": [
{ "type": "tags", "id": "2" },
{ "type": "tags", "id": "3" }
]
}
This response gives only the necessary data (in primary data attribute - data) to manipulate the relationship and not resources connected with relationship. That being said, you'll call /articles/1/relationships/tags if you want to create new relationship, add a new tag (basically updating relationship) to article, read which tags belong to article (you only need identity to search them on server) or delete article tags.
On the other hand, calling /articles/1/tags will respond with tags as primary data with all the other properties that they have (articles, relationships, links, and other top-level attributes such include, emphasized text, links and/or jsonapi).
They are different. Here is an example from my project.
Try Get http://localhost:3000/phone-numbers/1/relationships/contact you will get response like this:
{
"links": {
"self": "http://localhost:3000/phone-numbers/1/relationships/contact",
"related": "http://localhost:3000/phone-numbers/1/contact"
},
"data": {
"type": "contacts",
"id": "1"
}
}
You didn't get the attributes and relationships which is probably you want to retrieve.
Then
Try Get http://localhost:3000/phone-numbers/1/contact you will get response like this:
{
"data": {
"id": "1",
"type": "contacts",
"links": {
"self": "http://localhost:3000/contacts/1"
},
"attributes": {
"name-first": "John",
"name-last": "Doe",
"email": "john.doe#boring.test",
"twitter": null
},
"relationships": {
"phone-numbers": {
"links": {
"self": "http://localhost:3000/contacts/1/relationships/phone-numbers",
"related": "http://localhost:3000/contacts/1/phone-numbers"
}
}
}
}
}
You can see you retrieved all the information you want, including the attributes and relationships.
But you should know that relationships can be used for some purpose. Please read http://jsonapi.org/format/#crud-updating-to-one-relationships as a sample.

Related information about location in freebase are always null?

I'm trying to query freebase to find information about a specific city.
I'm able to find the city that I'm looking for but I need to get the description content as well as a few pictures.
My current query is
[{
"name": "san francisco",
"id": null,
"type": "/location/citytown",
"/location/location/geolocation" : [
{
"latitude": null,
"longitude": null,
"latitude>" : 36,
"latitude<" : 38 }]
"/common/topic/article" : [{ "id" : null, "content": null }],
"/common/topic/image" : [{
"id" : null,
"optional" : true,
"limit" : 15
"image_caption" : []
}]
}]
Which returns
{
"code": "/api/status/ok",
"result": [{
"/common/topic/article": [{
"content": null,
"id": "/m/0d6l_"
}],
"/common/topic/image": [
{
"id": "/m/02929wx",
"image_caption": []
},
{
"id": "/m/04j74y4",
"image_caption": []
},
{
"id": "/m/04j74yh",
"image_caption": []
},
{
"id": "/m/04j74yw",
"image_caption": []
},
{
"id": "/m/04j74z6",
"image_caption": []
}
],
"/location/location/geolocation": [{
"latitude": 37.775,
"longitude": -122.4183
}],
"id": "/en/san_francisco",
"name": "San Francisco",
"type": "/location/citytown"
}],
"status": "200 OK",
"transaction_id": "cache;cache03.p01.sjc1:8101;2012-07-24T21:50:06Z;0029"
}
I can't get the content value and the captions to be set.
Am I missing something ?
Where did you find the "image_caption" property? If you switch it to "name" you should get the names of the images (which are used as captions in some UI contexts).
The text content isn't available from MQL, but you can get it from the BLOB service in the old API or the text API in the new APIs using the ID that is returned for the article. e.g. https://www.googleapis.com/freebase/v1/text/m/0d6l_
p.s. If you just want the primary image, you might consider using the Topic API which will return you the image, it's name, the text blurb, and a bunch of other info in a single call.
https://www.googleapis.com/freebase/v1/topic/wikipedia/en_id/49728
Using the Search API will give you more robust name matching as well as give you a score which will tell you how likely it is that the query is ambiguous (if you get multiple matches with scores close to each other).
https://www.googleapis.com/freebase/v1/search?query=%22san%20francisco%22&type=/location/citytown

Resources