[api_module] Need some guidance on proper implementation

emergingdzns - 1 month ago

Ok so I have two websites that are two different clients (both sites are Pyro), but they want to work together (one site was a recruit deal from the main client). So in the first site (the "host" site) we have a bunch of users and a module, let's call it a "collectibles" module, with a bunch of streams that relate to a given item (or collectible). The second site (the "consumer" site) has a very similar collectibles module with nearly identical model fields etc. Because the host site has some subscription elements, the consumer site will be needing to access the API to look for corresponding records of their collectibles that are subscribed to the service that the host site offers. (Each collectible on both sites share a common "registration" number so I can correlate the collectibles between sites).

The consumer site will not be using the host site for SSO or anything like that. The users on the consumer site have records of their collectibles and on this list page, my intent is to query the API on the host site to see which of the owner's collectibles is subscribed on the host site and which are not. If the item is not found on the host site (based on the registration number) then it would provide a button to submit that information to the host site to create a record on the host site. In our case the information about the collectible would never change so we don't have to worry about keeping in sync. Here's the tricky part, not every user on the consumer side will already be a user on the host side. So, what I want to do is have it so that when the user logs in on the consumer side and loads their list page in the module, if their user record is not found on the host site then the first "submit" button they press to send their record to the host site would transmit their user record (minus password etc) to the host site api (which would create a new user record for them and then send an invite to complete their registration by setting a password) and then would add the collectible to the new user records on the host site. Subsequently, all the submit buttons would only need to send the collectible item information and the user id or something to link to.

In the host site, I've installed the API module. But here's where I'm needing some help...

Since not every user on the consumer side will be a member of the host site and we aren't doing SSO, I don't think I need to have an API client key for every user. Wouldn't make sense anyway I don't think because we have to have an API client/secret in the first place to even make the API connection to see if the user exists on the host site (based on email address). So, do I create a "fake" user on the host site that can be assigned a client id and secret that would be used simply for the oauth connection for the consumer? In the host site I can configure the end points to create the users when necessary and to assign the collectible ownership to the new/found user. Does this make sense or is there a better approach?

Answer

ryanthompson - 1 month ago

If you simply need API access not based on a user per say - I would personally just use a personal access token: https://pyrocms.com/documentation/api-module/2.0/usage/issuing-tokens#issuing-personal-access-tokens

They don't expire - they're singular (they still rep one user - maybe one specific for API access).

ryanthompson - 1 month ago

If you simply need API access not based on a user per say - I would personally just use a personal access token: https://pyrocms.com/documentation/api-module/2.0/usage/issuing-tokens#issuing-personal-access-tokens

They don't expire - they're singular (they still rep one user - maybe one specific for API access).

emergingdzns - 1 month ago

Ah ok so that's essentially what I was thinking but wasn't looking at it from the personal access token aspect. Cool thanks. I'm on the right track then. Thanks!