How to authenticate user on SSR?

By SSR do you mean server side rendering? If so, why don’t you just pass the user info necessary for rendering without any authentication?

Yes, SSR is server-side rendering.
I have to deliver a customized home page based on the userId or something, also I’ll be needing SSR to serve the inner pages (i.e after login). so without auth, calling data and injecting in HTML won’t be a possible solution.

Since it’s server-side, don’t you already have direct access to the user data needed for rendering? Just query the database …

Yes, I agree.
It would be helpful if you can elaborate sir.
I was thinking of cookies first, but if user blocks then whole system will go down.
later I found that usually when the user blocked cookies you would always store his data server-side and then use a token of sort in every URL
That’s why you see old PHP applications use Example Domain

But I am not sure to use them and couldn’t find a good approach for same.

Do not do this!

You give away session hijacking for free with such a system.

Just explain your users why cookies are necessary. Even the most paranoid people will enable them if you assure them, that they are used for authentication only.

In Europe you are even allowed to do that without telling the user (as long as you do not write to the cookie before the user actually tries to log in), but most sites simply tell the user.

In general, you will store an encrypted and signed chunk of data in the cookie, perhaps using a Phoenix.Token. In many cases its just the current users id, which you will use to retrieve the users details from the database as necessary (maybe in a plug that uses assigns then?).

Yes thanks @NobbZ , I understand that people will normally accept, but I wanna try something more solid.
What about sessionId, keeping IP Addresses of recently logged devices. I am able to see a problem with my RAM as I will be needed to keep a extra huge amount of data ( user * 3) in RAM, for fast access.
Any suggestions for same?

Using cookies is the most solid approach. You do not want to use anything else in the browser.

If you have other clients, feel free to otherwise sent the token from the client to the server in the request body, but do yourself a favor and never send it as part of the URL.

You’ll see only one IP shared for all workstations in my office, do you want to treat all of them the same? Do not do this, this is a very bad idea as long as IPv4 is still a thing.

As stated in question, I am looking for the approach for SSR auth part, so I just cannot get token for initial first request.

and actually, I didn’t know this thing, lack of knowledge in area.
Thanks

Thats why I said, when you do not use a browser, but when you talk about Client and Server Side Rendering, then you probably do use a browser. So consider it a notabene.

So the cookie approach is the most clean thing for a pure Server Side solution.

But perhaps you could use a mixed approach.

Use JavaScript to send requests, authenticate them as you wish, render the full page on the server and when received from the JS client, just fully replace the page. But you need to do a lot to have a working browser history or to maintain UX during load times on small bandwiths or high latency connections. Well, to be honest, the very same problems you have with full client side renderings in general…