Closed mohammadGh closed 8 months ago
Why not using the hooks?
I don’t see any advantage of renaming such internal apis
Thanks Sébastien for your quick response. But I don't think these APIs are completely internal. Because in the end, these two routes are added to the website APIs, and may be called completely from the front-end as a client-side fetch. For example, in the interesting Nuxt-Todos-Edge show-case, API [delete] /api/_auth/session
is called on the client side to logout the user.
Of course, it is possible to define two custom routes that act as proxies for getting and deleting sessions, but again the two original routes are added to the application's APIs.
In any case, if you think that customizing the get and delete session APIs is useful, I can add them to ModuleOptions
and use the module settings path instead of the hard-coded path in the fetch
and clear
composables, and open a pull request.
I don't really like adding options as it adds more complexity, I know by experience with Nuxt 1 and Nuxt 2.
@Atinux so this use case is failing where, I have a website and API hosted separately at example.com and example.com/api
Now when I want to implement the login, it works because I can use a seperate path for auth like /route/auth but when it comes to logging out the user, it uses /api/_auth and because my entire API is hosted on nginx at /api, this fails.
The API paths for getting and deleting sessions are hard-coded:
[get] api/_auth/session
[delete] api/_auth/session
The configurable APIs allow users to specify how they want to get and delete sessions.
Currently, in the module definition, information about the session and cookie, such as the name, password, and type of cookie, is read from the
runtimeConfig.session
. In the same way, the main path of the session API (for the get and delete methods) should be configurable, for example from module options.