JSON API for public apps?

[Mike521w]

I'm tossing around the idea of, sometime way in the future, building a React SPA for our Miva site, letting Miva handle the backend as a sort of headless ecommerce CMS. It may never happen, but the idea is on my mind, maybe just because I think it would be fun.

Meanwhile I need to make some updates to the customer account edit screen on our current site, so as a trial I'd like to write a drop-in React component that will handle the guts of the page (change password, change billing / shipping address, etc).

I'm not at all a security expert, so I'm wondering about whether this is possible to do securely. The system would need to be able to pull the customer's current account data and display it back to them in an editable form, and then send updates back as posts

The main problem I'm thinking about is, how will the system securely use our JSON API token / signature? I can probably set up a PHP script that pulls them from a table in the DB somewhere, and let the system grab them via a secure post/response, so at least they won't be hardcoded into the javascript bundle. But really what's the point of that - the PHP script would need to always respond with the token / signature, so anyone/anything nosy enough to find out the URL of the PHP script would be able to send a similar post and get the token / signature.

The more I think about it as I write this post, the more I think it won't work. For example even if I could somehow securely send a post to the JSON API to edit the customer's account, the app (or rather, the user's browser) would be able to edit *all* accounts that it knew, or guessed, the customer login for (the customer update portion of the API can use the login as the key).

Anyone have any thoughts / ideas? Maybe I'm over-thinking it or maybe I missed a much better alternative?

[cpp-dev]

The JSON API connects over HTTPS so unless you're planning on going around that somehow, you should be fine on a basic security standing.

Each customer account should have a single ID, thus the isolation would be to write the app so that it can only access the matching user ID.

If the customer is editing their own account, couldn't you use the built in Customer Auth system that Miva has already? That isn't going to sacrifice security and you don't need to do anything complex to make it work.

I did find this mentioned on the Docs page -- https://docs.miva.com/json-api/#clientside

It looks like they've thought of this, but it's not been fully fleshed out yet, as an endpoint for customers.

[Mike521w]

Yea the connection back and forth is secure, but I'm concerned about protecting the API token and signature

- I can't hardcode them into the javascript of course, because then they'd be available to anyone who snoops
- If I send a request to a PHP script that would respond with the token / sig, the user would be able to look at the response in their dev tools and get them
- and even if the user couldn't look at the response, as soon as they were received by javascript, they'd be exposed to the user and any malicious browser plugins they might have

Once a user or malicious browser plugin got access to the token and signature, they'd be able to do pretty much anything they wanted that the JSON API is capable of. So 99.9% of the time I could do it this way and have no problem, because really what are the chances that one of my users is malicious, or that they have a malicious plugin on their browser that's specifically set up to target Miva stores that use the JSON API. But it's still not a risk I'm willing to take

Thinking about it this morning, I think a much easier / better option would be to create my own Miva page that I expect to listen to posts from the user's browser, and respond with my own JSON responses. I wouldn't have to worry about authentication, or the user getting access to anything they're not permitted to access. That's probably what I'll do

[cpp-dev]

Making your own page sounds like it will be more in line with what you're wanting todo. Especially since it's intended for customer use, at least that's how it sounds.

As I've been looking over the documentation, it seems like JSON API is intended for use by store/site staff rather than customers.