I'm connecting to the v1 connect API to grab inventory for a couple items in my store. I'm using the PERSONAL_ACCESS_TOKEN
The end point is connecting fine, but it's returning a blank dataset, presumably because when i connected to v1/me
I only have the following permissions :
"account_capabilities":["EMPLOYEE_MANAGEMENT","TIMECARD_MANAGEMENT"]
Inventory needs "ITEMS_READ", is there a way to change this without having to use OAuth, or am i stuck making an oAuth request everytime i need to pull inventory?
I believe this is occurring because your Square account is a Multilocation account. Because of this, you need to access Connect API endpoints slightly differently:
Use the List Locations endpoint (/v1/me/locations) to get the id for each of your business's individual locations.
To access item, inventory, or payment information for one of your individual locations, provide that location's id as the value of the merchant_id path parameter (instead of providing me) in your request.
Note that the account_capabilities listed by /v1/me are different from capabilities described by OAuth permissions. Regardless, your personal access token grants you complete access to all endpoints for your own Square account.
Related
As per Google Assistant documentation for Smart Home, the agentUserId used in action.devices.QUERY is defined to 'Reflects the unique (and immutable) user ID on the agent's platform. The string is opaque to Google, so if there's an immutable form vs a mutable form on the agent side, use the immutable form (e.g. an account number rather than email)'
However there can be cases where the same device (with same agent user id) is attached to multiple Google Assistant accounts and in such cases a DISCONNECT request may result is ceasing report state for all accounts. The solution will be to add some unique ID corresponding to the Google Assistant account, however such information is not available in any request.
Has anyone seen similar issue and is my understanding incorrect?
The agentUserId is meant to be the user account on the smart home platform. SHP user '1234' may have a vacuum and two lights, but could be linked to multiple Google accounts.
During the account linking process, you would be expected to give a refresh and access tokens to allow for Google to have authorized control over these devices. If you assign unique access tokens for each Google account that signs in, you'd be able to determine which Google account the request is coming from.
At that point, once the user disconnects, you can use the access token in the request header to associate that with a specific Google account and only disable reporting for that account while not affecting other accounts.
So, yes the solution is to have a unique ID connecting to the account. While this is not passed in the agent ID, there is already a mechanism to make this association through the authorization system.
Alternatively, you could append a key in the agentUserId, ie. '1234-user#gmail.com'. However, this may have unintended impacts in the Home Graph. In a multi-user home, you may end up seeing the devices duplicated because Google doesn't have the right information to deduplicate.
I'm running a Spring app on Kubernetes. App is authenticated via keycloak (also run on k8s).
The problem is that in case when Kubernetes will have configured more than one edge node I can connect only from node which is configured in keycloak.auth-server-url in the Spring app. On other edge nodes I'm getting Invalid token issuer error. Do you know any solution for that problem?
Remember that first, during keycloak configuration you have to create a new client with the name persons-app specific for the application. You can do that under Clients in the left column and then clicking Create.
Then proper redirect URL needs to be configured.
After setting up the proper client, a new role user is added to Keycloak. This role can later be assigned to individual users in order to define appropriate access policies.
The last thing you have to do is creating an actual user and assigning the newly created role to that user. This can be done by clicking Add User under the page Users.
Next, you have to set a password for the user. In this example, it is the standard password for example projects (i.e. password).
Roles of a user can be managed under the tab Role Mappings. You have to add the role user to Assigned Roles.
That's it. Keycloak is now ready to be used and has already a very (very) small user base. Now you can proceed to the actual application, which should be secured.
Remember that in order to store relevant information and configuration, a PostgreSQL database must be set up first.
More information you can find here: spring-keycloak.
I've created a service account in G-Suite and delegated it domain wide authorization so that I can collect information on all the Drives within the suite.
The problem I've come across is that I need a list of all the users within the domain. To do so I can call the Directory API, but the problem is that I actually need to do that as one of the admins. The problem is that I can't know who the admins are without using one of the admins(or users? I confirmed the call to the directory API with a superadmin account). Is there a way to call the Directory API without a user email? Or is there a way to as the service account to get a list of the admins so that I can make API calls on their behalf?
To use Directory API, you must** impersonate one of the admins of the domain, as you say. There really isn't any way around it (as far as I'm aware) - you must ask the admin who's installing your app to provide their email address.
** For some activities, like listing all users, you can impersonate an end user, but that doesn't solve your problem.
I am building an online web store for a client of mine. I want to use all of their current inventory in their Square system to seed the online store.
It seems as though V1 of their connect API only supports /items which is fine.
However, I can not find a way to get the client's token. I expected that when I signed in to the Developer Portal with the client's credentials that I would be able to access their token, but it just asked me to create my first app -- which would be empty.
Is there a way to do this without OAuth? Since it is being used as a store, I do not want there to be a chance of the session expiring and customers hitting the store and seeing no items.
TL;DR How to connect an existing Square instance to the Connect API?
You're almost there.
If you have the square account credentials, go to connect.squareup.com/apps/ and click on the create app button. Pick something for the name, and after you finish that you'll see a page with the OAuth credentials, as well as the personal access token. If you are just making an app for one merchant, the personal access token will be all you need, and easiest to use.
Apps are just ways to organize API credentials, fairly distinct from merchant accounts.
Is there something you want that the /items endpoint doesn't give you?
I've got a project made of two websites:
The front : A Laravel website without database and logic (just showing static pages and my javascript)
The API : A project using Lumen/Dingo API with my endpoints, my database, my logic and my models
I want to allow my front to ask data to my API depending the user.
Ex. I want to log the user, retrieve his friends, add some post to his
account, etc. (from the Javascript)
What is the best solution?
Using an identification per user (using o-auth or JWT)
Allow my front project to ask to my API then each javascript call needs to use my front without knowing my API) (In this solution I need to create routes similars to my API's routes)
Identification per user is always a better solution as the claims can be decided per user, also in future when it is required to provide permissions to access API based on claims or roles, it becomes easy to give information using the claims and amount of access you can give to a specific user.
So the way it will work is:
There will be identity server which will be containing the list of users in the system, and also the clams and scopes per user.
The API project will trust the identity server, that means any token provided by the identity server can get verified.
Based on the token per user your API app can decide how much information you want to give to the user.
That way in future you can have methods based on roles, claims and users will be provided with only the information that they have access to.