fix popup auth broken due to new COOP header

[k-yle]

Caused by openstreetmap/openstreetmap-website@2ff4d6 , Closes #137

window.opener can't be used anymore, so we have to use a BroadcastChannel instead. BroadcastChannels only support comms within the same origin, so this shouldn't introduce any new security risks in comparison to the existing solution, to the best of my knowledge.

This is a breaking change because users need to manually update their land.html file.

Unfortunately, this also reverts #135, which isn't possible anymore, since the popup window sets a restrictive COOP header

[bhousel]

Well this is the first I'm hearing about it.
I'll have to give a big change like this a proper review.

[mattrobmattrob]

FWIW, confirmed this change works in an internal iD fork. Let me know if I can be of any help to you all otherwise.

[1ec5]

I’ve only used BroadcastChannel on occasion, but this looks about right to me.

[HarelM]

How do you know if the popup window was closed by the user after this change?
Here's a similar comment I added to the change made in OSM:
openstreetmap/openstreetmap-website@2ff4d6a#commitcomment-161835429

Any insight would be helpful. Thanks!

[k-yle]

How do you know if the popup window was closed by the user after this change?

Correct me if I'm wrong, but the COOP header intentionally makes this impossible, hence why this PR also reverts #135 🫤

This also prevents a dodgy referrer from polling Window#closed to track how longer the user spends in a new tab

[HarelM]

That's my understanding as well, I hope you might have found a way to work around that...
GenAI told me that I can poll for popup.name and if I get an exception, I might know that the popup is still open, but on a different URL. I doubt the exception won't happen after the popup was closed too, but I haven't tested it yet...

[jjiglesiasg]

HOW THIS COULD BE SOLVED?, THERE IS NO POSSIBLE TO LOG IN

[bhousel]

I tested this out with a local build of Rapid and it seems ok.

I had some concerns about how the messages get passed around,
per https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel

Messages are broadcasted via a message event fired at all BroadcastChannel objects listening to the channel, except the object that sent the message.

So it sounds like a malicious app on the same origin could just listen for these messages. However I agree that this doesn't open up any new security risks, because anyway an app on the same origin can also just inspect the localStorage keys.

I'm not sure whether this was ever documented clearly, but this is why multiple osm-auth apps really need to be deployed like:

https://rapid.example.org
https://osmcha.example.org

and not

https://example.org/rapid
https://example.org/osmcha

because the latter shares localStorage and the keys can conflict.