#Localstorage drop upon moving from 4201 to 4200 port

130 messages · Page 1 of 1 (latest)

loud sable
#

Hey guys, I have such setup :
Two front-end applications running on 4200 and 4201
Two back-end applications running on 8080 and 8082.
The problem is that there's a need to interact with a page on 4201 that involves moving to other hostname to work at - but it results in dropping to a login page once you hit 4200 - because local storage, which holds auth token, gets wiped.

Tried to make a workaround with nginx which acts as a reverse proxy serving on 8010 port.
At this point, application is accessible but the problem is still same - interacting with a page on 8010 still forwards on 4200, resulting in exact same issue (the idea was to mock a 4200 port with 8010 to have same host).
Tried to intercept a url on-a-fly to swap ports - but the nature of the client redirect does not allow to do it either.
What are the possible ways to cope with it to achieve two front-ends work under the same host to avoid wipe ?

This works on a cloud machine with DNS configured (no localstorage wipe) - but on local it's not possible.

#

@dreamy sleet please evaluate a reason of previous ticket closure or at least provide corresponding ticket name which could be seen as a "duplicate" in help topic.
There is nothing related to this in help category at all.

dreamy sleet
loud sable
loud sable
dreamy sleet
loud sable
orchid spoke
#

Stumbled upon this as I saw the help section suddenly being active.
My input:

  1. Do not spam communication channels. Keep messages relevant to the channel they are in. Do not send the same message or question across channels or platforms (ie. StackOverflow). Be patient. Someone will be with you when they have a moment to help
    Emphasis mine.
    The rule and intent behind the rule is self explanatory.

You can make a case that after the question kinda died down in #questions it no longer pertains to the channel and is thus okay to post here.
A small acknowledgement in that direction and only posting the first thread after the discussion in #questions died down likely would've already sufficed.

dreamy sleet
#

@loud sable Mind most people reporting duplicate are active helpers, the same ones discovering they took their personal time to answer a question the community already answered somewhere else.

As most people only comes here to ask questions and not help, their time and help is precious for us

orchid spoke
#

Elaborating on #questions message

The idea is to basically make your browser treat localhost like a normal domain.
We do that basically by just manipulating DNS by messing with the /etc/host file to tell it "this domain resolves to localhost".
In my case, I enter my prod domain, in order to have conditions as close to prod as possible while running my servers and frontends on my local machine during development.

There are more elegant approaches most likely, I never bothered with them.

For just http, it really should be as simple as just doing the entry in etc/hosts. I say should because my own setup is a bit more elaborate, as I basically do an entire setup of building docker-images and starting fresh containers for my frontend and backend that then run under localhost.

If you also want https, you'll need a self signed certificate floating around that your reverse proxy that does the https can use instead of a "real" certificate.

Sadly chrome does not like self signed certs at all and I have completely failed to get mine added to wherever they need to be added in order for the browser to accept them.
Works with firefox though after you tell it that yes, you're aware this is a self signed cert.

#

Note that this works because there's a reverse-proxy in front of it all that makes sure requests get wired to the correct frontend/backend.
In my case that's caddy, so basically any HTTP request from the browser gets resolved to localhost, which reaches my caddy-instance, which then routes the request to the frontend- or backend-container, which then behave normally

#

I'm not sure if you'd need caddy if you can live without https in a local environment, it might be necessary, I haven't tried.

loud sable
orchid spoke
loud sable
orchid spoke
#

But again, I might be wrong

#

The way it works is pretty much that you enter the domain in your browser, browser resolves domain to localhost and fires automatically on the http or https port since that's where browser's fire their http requests.

That then reaches the reverse proxy (in my case Caddy) which listens on 443 automatically and based on the url you entered can then forward the request to localhost on the correct port.

In my case for example this is what the config looks like:

{
    email {$NS_DOMAIN_SSL_EMAIL}
}

www.{$NS_DOMAIN} {
    redir https://{$NS_DOMAIN}{uri}
}

{$NS_DOMAIN} {
    reverse_proxy localhost:5123
}

NS_DOMAIN is an environment variable, but you can see that all requests get shifted to localhost:5123 for example

loud sable
#

The problem is having a reverse proxy ends up redirecting me to real port and drops local storage

orchid spoke
#

localstorage in your browser should be running under whatever domain you end up running this, so even if you swap from one frontend project to the next, they still run under the same domain and thus have the same localstorage

loud sable
orchid spoke
loud sable
orchid spoke
#

If you "unify" them by putting them behind a reverse proxy they'll studdenly share localstorage

loud sable
orchid spoke
#

Yes, because the browser doesn't communicate directly with your project-server, it communicates with the reverse proxy.

#

Oh wait, that might actually mean you can save yourself the /etc/hosts entry

#

Basically have caddy running on whatever localhost port, enter localhost:<caddyport> in your browser and have caddy do the routing

#

Since the browser only ever sees localhost:<caddyport> it won't care with regards to localstorage.

#

You can also use whatever other proxy, caddy is just the most trivial to configure

loud sable
loud sable
#

@orchid spoke It didn't work. That was I thought of - regardless of the configuration of proxy and /etc/hosts/ and whatever, frontend client internally resolves a url in an application, resulting in redirecting from http://dev.local:8010 (proxy which gathers both frontends) to localhost:4201/ , bringing back the initial problem

shrewd dove
#

The problem is that there's a need to interact with a page on 4201 that involves moving to other hostname to work at - but it results in dropping to a login page once you hit 4200 - because local storage, which holds auth token, gets wiped.

This suggests 4201 will clear 4200's localStorage, actually it can't.

Are you trying to implement oauth provider? Where 4201 is the provider (Including its UI), 4200 is the demo app

#

frontend client internally resolves a url in an application, resulting in redirecting from http://dev.local:8010/ (proxy which gathers both frontends) to localhost:4201/

frontend won't know itself is on localhost:4201, it can't invent a port number 4201, there must be some configuration that is set as localhost:4201. Not even ssr will redirect you using absolute.

loud sable
loud sable
shrewd dove
loud sable
shrewd dove
#

So that is not a reset

#

nothing log you out of 4200

loud sable
shrewd dove
#

If i am in localhost:4200, i go to www.google.com manually (changing of addressbar), and press Back, i am still logged in

loud sable
shrewd dove
#

Which is easy, IF it is fixed to 2 (Won't have another 4206)

loud sable
shrewd dove
#

Will you have 4202, 4204 in your future

#

I don't get?

#

You described it as a reset

loud sable
shrewd dove
#

So you want the answer?
Will you have 4202, 4204 in future or just 2?

loud sable
shrewd dove
#

Ok. Will 4200 only be the one incharge of getting authenticated.
i.e.
Wil the user starts on 4201 and go to 4200.
Instead of starts on 4200 and go to 4201.

loud sable
shrewd dove
#

They can starts on any port?

#

Then visit another port

loud sable
shrewd dove
#

and local storage won't persist upon moving to different origin
For n00b that is true

#

Just answer

#

I need the detail to formulate the solution

loud sable
#

how calling me a noob supposed change a reality of origin routing?

shrewd dove
#

Bye

#

Waste my time

loud sable
shrewd dove
#

I am still here

loud sable
#

Instead you came here to shake the air out and then just toxed on someone else

shrewd dove
#

Then I just give you the answer for 4200, 4201, you want the minor changes in future

orchid spoke
#

Ah, you guys still going?

#

Back to work with me then

loud sable
shrewd dove
#
  • When you move to 4201 from 4200
  • You are at 4201 now
  • 4201 is supposed to open a hidden iframelocalhost:4200 that must check its parent.origin is localhost:4201 (for security)
  • That iframe will parent.sendMessage(localStorage's seriailized state), the parent happens to be 4201
orchid spoke
#

Ah, proxy_pass alright, hmm let me think

#

And at what specific point do you jump from localhost:<nginxport> to localhost:<projectport> (which shouldn't happen) ?

loud sable
orchid spoke
#

Hmm do you use SSR?

loud sable
loud sable
loud sable
orchid spoke
#

Check, at a first glance as a fallback you could build your application to serve the files on localhost rather than proxy-pass.
For the behavior that it redirects (I assume you click on an element and it triggers an actual page-reload to the new port?) I'd need to puzzle something out

shrewd dove
#

angular will only know 8010 if it checks window.location.port

loud sable
shrewd dove
loud sable
shrewd dove
orchid spoke
loud sable
orchid spoke
# loud sable yes

Okay, that doing a page-reload is expected. And when it does so it also changes the port?

loud sable
orchid spoke
#

Hmmm I'd need to set up a minimal reproduction locally and play around to double check. The fact it changes the ports here is odd to me, as I don't think it would do that for just normally compiled builds (which is why it works for you in prod)

#

So the fact there's 2 active dev servers running rather than just 2 different sets of files being served is making it behave differently than it does i.e. in my own project

loud sable
orchid spoke
loud sable
#

But it's not stable 💀

orchid spoke
#

Yeh, just that DNS (resolving the string to an ip) is not the necessary part here from what I can tell, it is the fact that you always talk to the same reverse-proxy that then serves you the file you're requesting

#

Could you post the URL of the element you click on that routes from appA to appB?

loud sable
#

You mean, to share it here in chat ?

orchid spoke
# loud sable What do you mean ?

In order to jump from appA to appB you click on an element somewhere.
I assume that is either a <a href="localhost:????/other/app"> stuff </a> or a button that does windows.location.href = ???
I'm curious about the specific value you dump in there

loud sable
orchid spoke
#

Or console.log the url or sth

loud sable
shrewd dove
# loud sable I will try to debug it and investigate what is going on in there, but I suppose...

Exactly. It is not angular computing localhost:4201 using its environment (window.location)

In your frontend1. You have: ```html
<a href="http://localhost:4201/frontend2">Go to frontend2</a>

In your frontend2. You have: ```html
<a href="http://localhost:4200/frontend1">Go Back to frontend1</a>

These are configurations (In prod you are supposed to change their value to prod href).

So you just need find those configuration and change those configuration to use 8010 instead```html
<a href="http://my.local:8010/frontend2">Go to ....</a>

orchid spoke
#

As nova also pointed out

#

Only then can the origin stay stable at localhost:8010

#

Basically, you must not ever link directly from appA to appB, it has to always be appA => proxy => appB and vice versa

#

At least if you want to have localstorage stable

loud sable
#

so a BACKEND performs redirect

#

wow

#

and that is the reason why none of the configurations succeed

orchid spoke
#

Okay that is hilarious 😄
Always the thing you least expect is the thing that backstabs you the hardest

loud sable
shrewd dove
#

angular won't know this number 4201, maybe it is backend that does the redirect
I already called this

loud sable
shrewd dove
#

backend is also based on configuration anyway.

Your port in angular points to 8080 / 8082

Your port in Backend will also redirect back using configuration 4201 / 4200

You can try to locate them (if you also own those codebase)

loud sable
#

being a fullstack is funny tho

orchid spoke
#

Honestly, fullstack is a misusage of the term nowadays I feel.
Given how complex BE and FE now are at times, if you need something really complex/scaling you're not going to get a person that can do both with the necessary depth except for a very small crowd of people that absolutely love the stuff

loud sable
#

frontend devs do not understand what is going on be

backend devs either don't give a hell on what is going on on fe

a person who knew is faded away centuries ago

shrewd dove
#

a person who knew is faded away centuries ago
I remote viewing your codebase already since first message.
frontend won't know itself is on localhost:4201, it can't invent a port number 4201, there must be some configuration that is set as localhost:4201. Not even ssr will redirect you using absolute