I'm looking for a way with Sylius to dynamically display the product list. Like asking the server for a specific set of products (search with parameters I suppose) asynchronously.
The doc seems to suggest the use of oauth authentication is mandatory but it's not what I'd like, or at least not systematically. So my question is, can I and how can I make an api call for "public" parts like product list but anonymously?
Thank you.
From the documentation :
Sylius has the OAuth2 authorization configured. The authorization process is a standard procedure. Authorize as admin and enjoy the API!
User has to have the ROLE_API_ACCESS role in order to access /api resources
So unless you create your own public api set to display products informations this is not possible with base Sylius api.
You can use the SyliusShopApiPlugin, which is currently in development. With it you can make anonymous and public API calls, e.g.:
/shop-api/taxons/t-shirts/products/?channel=US_WEB
to get all products in the t-shirts category.
I didn't find yet any documentation, but you can check the tests, e.g. https://github.com/Sylius/SyliusShopApiPlugin/blob/master/tests/Controller/ShowProductCatalogApiTest.php to get more examples.
Related
I have been experimenting with the REST API using my logged in user account's token to then make PUT requests on my user record to update some custom attributes.
In order to get to this work I had to grant my user account the manage-users role in Keycloak, prior to this I was getting forbidden responses back.
I can now make the PUT request successfully, and after logging out and logging back in I can see the updated attributes I set in my PUT request.
But I have now allowed my user to be able to manage all users in my realm, which I dont want to allow.
Instead I only want to be able to update my own account details.
I know the user can view their own profile and make changes on the Keycloak provided screens. But for certain custom attributes I want to be able to do this from the client side application they are logged in to, so using the REST API but not granting them a role that could allow them to update other users details.
Is this possible?
According to the User section Keycloak's Admin REST API, this is not possible.
One solution would be for your client app to send the update request to a backend. The backend will verify that the update request is legit (aka the JWT is verified and the update does apply to the user requesting the change).
Another solution would be to theme the User Account Service's screens to add input fields for your custom attributes, as the documentation says that:
This screen can be extended to allow the user to manage additional attributes. See the Server Developer Guide for more details.
The second option seems the more secure. I hope that helps.
This seems to be possible with the Account Management API.
Unfortunately, I didn't find any official documentation about that. However, there's an example in Keycloak that demonstrates how to do it.
I am staring at the DocuSign REST API Guide and I see no request to update, say, User LastName. It looks like DocuSign may regard this top-level information as immutable for security/identity purposes. These are the PUT operations I am seeing related to users:
/accounts/{accountId}/users/{userId}/custom_settings
/accounts/{accountId}/users/{userId}/profile/image
/accounts/{accountId}/users/{userId}/settings
/accounts/{accountId}/users/{userId}/signatures/{signatureIdOrName}
/accounts/{accountId}/users/{userId}/signatures/{signatureIdOrName}/initials_image
/accounts/{accountId}/users/{userId}/signatures/{signatureIdOrName}/signature_image
/accounts/{accountId}/users/{userId}/social
Yes, it looks like /accounts/{accountId}/users/{userId}/settings is what I am looking for but this request covers only userSettings, signerEmailNotifications and senderEmailNotifications.
Am I missing something?
Some of the functionality in DocuSign is not exposed to public API for security reasons. We don't want people to change people's identity for example. So not every single setting is going to have a full CRUD operation set.
Maybe it would be helpful to hear what you are looking to accomplish? Here is the list of common integration scenarios: https://www.docusign.com/developer-center/recipes - it might help.
I'm doing a GET for customers with a given email address (there will only be one). Before displaying the returned information, I need to authenticate the user, but I can't see a way in the docs that allows providing a password as a parameter to a GET. In fact It only seems to be possible to provide a password when creating (POSTing) or updating (PUTting) a customer. Is it possible to authenticate customers via the API this way?
from what I understand - _authentication is only supported for POST and PUT on customer objects. I believe it is intended to create a customer who can login and stuff like that.
Can you explain your use case and maybe there is a workaround..
is there a way to fetch the venues search in iOS without the user entering his password or showing some foursquare oauth website?
I don't think that this oAuth makes any sense for this kind of request, it should be just an REST api like so "https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC"
but this one is deprecated =/
Any thoughts?
It's not deprecated, you're just missing the "versioning" parameter that specifies what version of the API you're trying to use.
Requesting https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC&v=20111107 will remove the warning you saw in your response
Add a query string parameter to your request as follows..
&v=20111119 // Choose a proper version.
Update: this is actually a date. So make sure you send current date in yyyymmdd format against v parameter.
According to FourSquare's docs page on venue searching an acting user is no longer necessary:
Some endpoints (e.g. venue search) allow you to not act as any
particular user. We will return unpersonalized data suitable for
generic use, and the performance should be slightly better. In these
cases, pass your client ID as client_id and your client secret as
client_secret. Although the draft 11 of the OAuth2 spec provides a
mechanism for consumers to act via token entitled Client Credentials,
we do not currently support this.
I am new to both .Net & RESTful services.
Here is the object hierarchy I have in the database: Users->Folders->Notes.
The API: GET /api/note/{noteid}
would get mapped to the repository call
NoteRepository::GetNote(userId, noteId)
Notice that I am passing on the userId to make sure that the note belongs to the logged in user for security purpose.
Is this the right approach? Meaning, every repository call would have the first parameter as the userId to check if the object being accessed belongs to the user.
Is there any better approach?
You don't need the User Id since the
GET /api/note/{noteid}
is indeed unique.
A valid scenario for adding the id would be:
GET /api/{userId}/notes
And then if you want a specific note you can:
GET /api/{userId}/notes/{noteId}
I would implement security at the entry level. whether the user has rights to perform a method on that specific resource. A role model approach would be fine.
Regards.
I would also introduce the user id in the API, because of Stateless and Cacheable constraints described in the Wikipedia REST article.
However, if I check Google Tasks REST API, they don't include the user id, same thing for Twitter API, so it seems a trend not to include the user id. If someone can shed some light I would be grateful.
UPDATE: Thinking more about it, if the noteid is unique across all users, there is no need to include the user id, so a GET /api/note/{noteid} is fine.
However, the logical parent in a restful interface would be GET /api/note/ to get a list of all notes, and here I've the objection, since the list would differ according to the user requesting it, making it non cacheable.
As for your dot net part I think that passing the userid among dot net methods is perfectly fine.