Closed rjherrera closed 1 year ago
I think it's a must. Definitely would add it.
Like 👍 I have one doubt, I've seen/used two different approaches in api interactions, that have small difference:
simple_token_authentication
, which needs headers for user email and tokenShould we enforce one or the other? Or give the option?
Being very biased, I think our mobile projects couldn't use the CSRF approach. If we want to have the same Axios configuration for both web and mobile applications I would enforce the simple_token_authentication
one.
I'd prefer a hybrid approach. Forcing tokens on projects that mostly use Vue for smaller components increases the complexity of keeping all states synced, especially when the APIs are only used internally.
Interesting, I hadn't thought about it. I feel like the approach with CSRF is a bit easier to configure than the one with the token, which implies adding the gem and a bit more of config, so for a project wanting to use the CSRF approach, it would be easier to go back from the API one.
I'm not sure if this is a good idea, but maybe as many projects do, we could include in the "config" file both approaches with one commented and one uncommented. Something like "if you want to use this approach uncomment this line".
Or maybe directly ask in the cli prompt, and make this an independent recipe, asking for token, csrf or none.
closing this as axios + config was added in #412 and csrf token in #426
I'm not 100% sure about this but I would love to discuss it. I think it would be useful for projects to add axios if vue and api are selected in the project, and bundle it with our opinionated version of the configuration, that is, including the interceptors and headers for the axios instance.
I see this being used in various projects and we are not following a standard, implementing it at potassium level would solve this in my opinion.