Problem:
SSR has some benefits over CSR, which I'd like to have; for example, page meta-tags are delivered to client in the raw response and not in the rendered response. However, for some reasons it'd be very good for us to do all the requests on client side. That is, I like the fetch hooks to be executed on client.
I know I might be going the wrong way, but is there a way to have a client-side-only-requests SSR mode?
What I've tried:
I managed to defer fetch hooks to client using the global mixin that has a fetchOnServer: false parameter which gets injected in all pages and components. But I had another issue:
We are using #nuxtjs/auth-next (v5) for authentication and it fetches the user API on server in SSR mode unless you set user: false in nuxt.config.js file. So after setting user: false, I manually fetched the user API on all my layouts' created hook. Now the problem is that whenever I click on a link that is a nuxt-link, this.$auth.user is reset to an empty object.
Related
I want to build a simple Next.js route that handles payments. In that route's handler I'm commentating with a third-party service via fetch to process a payment. One of the headers is a token (a secure token that should not be visible to anyone). I'm keeping the token in a string variable inside the route handler and using it in the fetch call.
My question is, is this safe? Is the API folder exposed to the front-end like everything else?
Everything added into the api folder will never reach the client side, however is recommended and considered as a good practice to save your sensitive data in .env file
API folder is not exposed on frontend you can safely store the token it will not be visible on frontend
once you add code on you /api folder it will be on server side unless you expose your token through res.send/res.json() or show the source code to other people then they will see your token. if you want you could add your token in environment variables
I'm trying to implement authentication in a Nuxt app using the Vuex store, and I hit a snag. Here's how I do it:
A middleware acting as route guard reads the value of an isAuthenticated in context.store to decide whether or not to redirect to login page. Upon completing login, the login page component mutates the store turning isAuthenticated to true before redirecting the user to their intended page.
Problem is, by the time user has completed login and is being redirected, the middleware still reads isAuthenticated as false. I'm guessing since the middleware is an SSR one its store isn't synced with the client's yet.
Looks like I need to do any (combination) of the following:
Sync the client's and server's store somehow.
Persist Vuex on SSR using a plugin or by writing my own persistence plugin.
Ditch Vuex as authentication mechanism entirely and come up with something else.
How do I work around this?
I have a question regarding the possibility to change the backend occ endpoint for the login.
In the default behavior, an auth object is created in local storage.
I changed in the app.module the default login: '/authorizationserver/oauth/token', to a different endpoint (/ourowntestserver/oath/token/test). After the change, the backend-side works as it has before, but on the front-end side, the auth object is not available in the local storage anymore.
In the Spartacus source code I can see an OAUTH_ENDPOINT with the same endpoint '/authorizationserver/oauth/token', used in an open-id-token.service, but I am not sure if that service is responsible for actually saving the token and if I have to extend it in the storefront app along with its store(actions, effects, etc.) too.
Are there any other changes that have to be done for this to work, or am I doing something wrong? Is it possible that the issue could be still back-end related?
Any help would be appreciated. (edited)
I would start by inspecting ngrx actions in devtools. Look for LoadUserToken and LoadUserTokenSuccess and LoadUserTokenFail actions. Look at their payload if everything there looks ok. Maybe the structure of response is different than the one returned from the default hybris OAuth server. Then you might need to create your own effect and handle the response a bit different than we do this by default.
The OAUTH_ENDPOINT is not currently customizable and it is being fixed right now for the 3.0 release. It'll have new auth module structure and allow for easier replacement of OAuth server.
open-id-token.service.ts is only used with Kyma module when you also need apart from access_token the id_token from OAuth server.
I want to understand whether nuxt-auth uses serverMiddleware and if not how can i implement one. I want to make my admin panel really secured, I have my backend secured however even if someone manages to overcome auth middleware on the frontend, which won't be that difficult(if auth Module uses client-side middlewares), I don't want nuxt to provide him/her with the layout and all pages even though I know that he/she is not going to be able to do anything because my routes on the backed require token verification and account data. If you can, please provide some info on the subject. Thanks!!!
So in short you cannot use the middleware provided by the #nuxtjs/auth plugin as a serverMiddleware, you can only use it as a normal middleware.
But that doesn't mean that it's insecure, normal middlewares actually executes both on server and client side before the page is rendered, so if you want to execute a middleware that will throw a 404 if the user isn't logged in you can do this in a normal middleware too, the serverMiddleware's capabilities are actually limited, you can't access nor the store or any client side information, because you only get (req,res, next) as parameters, and since Authentication is stored in store and cookies you can't make it work in Node.js only. This is a good example of what you can use serverMiddleware for: https://jackwhiting.co.uk/posts/handling-redirects-in-nuxtjs-through-middlware/
If you console.log something in normal middleware you should be able to see it both in your developer console and bash where npm run dev is running, this would mean that first the server executes it and then the client side too.
I have an API which I consume from a VueJS app, backend is handled through Laravel 5.2.
I have setup automatic session timeout after 15min, but if happens you're in the site and try to do anything, I have a loading screen, and it freezes as you're unauthorized.
I wanted to know if there's any global method to read Unauthorized response when all requests are made.
I don't know what this is called, so I wouldn't know how to properly Google the feature.
I'm using VueJS Resource $http library to manage all requests.
Thanks!
I've finally made my way to the right documentation, it was under Vue-Resource, and these are called Interceptors.
https://github.com/vuejs/vue-resource/blob/master/docs/http.md