Develop Reference

Next.js fetch a token from an api on initial render and store it

I'm building an application using next.js, there is a need to fetch a guest token from an api and set in the cookie as it would be needed throughout the application. So the first thing I want is the token to be set in the cookie before any page is loaded.
I'm migrating from react, there this logic was there in the app.js file and it was a single page application.
I tried putting the logic in getServerSideProps in the home page, it worked fine and the cookie was set, but the issue was if the user go to any other page first directly, the cookie won't be there. To achieve that we have to duplicate this code in that page as well. (which I don't want as there are lot of pages)
Then on further research, I came to know that we can use getInitialProps in the _app file, that fetches the initial data for all the pages but it comes with a warning (This disables the ability to perform automatic static optimization, causing every page in your app to be server-side rendered.) Not sure if it would be ideal for this case.
Is there any other solution, like some kind of wrapper we can use on top of _app to fetch the token server side and store it.
I'm new to next.js, please help me with this.

If you want to share the same server side logic to all the pages you could use next middleware or next custom server.
Consider that middleware use a subset of the nodejs runtime features so to perform http request you have to use the custom server. AIf you want you can then left to the middleware just the set/check of the cookies.

Storing login token in react and typescript

I have a typescript React app and I have a singleton DataStore.ts class that allows my React app to connect to my REST backend. The DataStore class handles everything having to do with the backend: login, logout, getting/setting/updating data etc. It uses MOBX for global state storage, ie any server data that I need to store is just assigned to #observable member variables in my DataStore class. When I login, my backend provides a token for subsequent API calls, and I store that token in the DataStore instance.
What problems are caused by just storing the token as a member variable in my DataStore object. It seems most people store the token in sessionStorage, but I'm not quite sure why this is better than storing it the way I'm storing it. Does my DataStore instance go away if someone refreshes the browser tab? Please explain.

How to manage admin side in Nuxt (vue.js)

I want to protect my admin interface inside nuxt.js.
Protecting the data is easy with an authentication on the API, but i don't want any user to see my admin interface by simply modifying the client side authentication code.
I was thinking about creating a second app only for admin but is there a better way ?

Shopify GraphQL CustomerAccessToken

I'm currently customising a Shopify App, allowing users to edit their profiles.
I am using the Shopify Webfront API with GraphQL, specifically the "CustomerUpdate" mutation:
https://help.shopify.com/api/storefront-api/reference/mutation/customerupdate
Calling the GraphQL end point using jQuery AJAX.
However, the method requires a CustomerAccessToken parameter but I am unsure how is this generated; the Customer Shopify Liquid class does not have it,
and the main searches for Shopify CustomerAccessTokens end up revolving around Shopify API Tokens.
Any help would be greatly appreciated.
TLDR: Unsure how to generate the CustomerAccessToken for the GraphQL CustomerUpdate mutation.
Cheers
Xavier

Click the getting started link on the API documentation. Follow the instructions for the type of API you will be using.
You can get a storefront access token by creating a private app or by using the REST API.
Customer Access tokens are created, deleted or renewed through a API calls.
In general, you would send the same username and email to the create access token that you send to create customer. You would then use that access token to update the customer.

Security in Angular2 with TS

I want to build a web application using Angular2 with TS.
I read several tutorials about authentication in Angular2 and they say, that I have to implement the following things.
index component (public)
login component (public)
my private component (private)
All this components are routed with the Angular-Router and protected with some guards.
But I think that this guards are not really secure. The routes are guarded but the components are there somewhere in js on the client.
Some "js-hacker" could access the private component without permissions.
Am I right with this thought?
My solution would be to request the private component during the authentication request and returning it only if the user has permission.
But in this case, I had to split up my application in a login part and a private part. (Seems like overhead)
Another solution would be to send a token with every request, so that the "js-hacker" is able to see the component, but not its data therefore it's useless for him. (But this token needs to be stored)
Please help me to decide which way to go in terms of security, or suggest me a better one (I would prefer a better one...).
Thanks.

You'd use *ngIf to conditionally attach your secured component on a valid authentication status. If whatever you bind the *ngIf to evaluates as false, it won't just hide it from view, it will completely remove the component and everything inside it from the DOM.
If they knew what they were doing, they could still look at the source code for the component, yes, but as you surmised, you'd want to keep sensitive data out of the source code and only grab it from somewhere secure for authenticated users.
You should really look into Google's Firebase. Firebase can handle authentication for you much more securely and robustly than you could yourself and you can use Firebase Realtime Database to store sensitive data and only send it to the client when users are authenticated. It's incredibly simple, works very well with Angular (AngularFire2 is the official library though it's not necessary), and it has a ton more features than just database and authentication. Trust me, you will not regret it.