GICodeWarrior

SAML implementations can protect against this by turning IdP-initiated requests into an SP-initiated request. On the SP-initiated responses, there is an `InResponseTo` field that can be validated (or `RelayState` can be made to work).

The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.

One of the issues I've run into with Tailscale OIDC is that an email domain must be mapped to a single tailnet. So if my IdP has consultants or if my domain contains multiple businesses with different tailnets, I need to do some domain mapping in my IdP and train users to login with that special non-email address.

This isn't strictly a limitation of OIDC, but I do see this issue more often with OIDC implementations. With IdP-initiated flows, the app doesn't need to know who's in my IdP ahead of time.

While not as good as a proper refresh, you can use alternating black and white drawing to help clear an area of the screen.

ctrl+mouse wheel triggers the application zoom in most cases. However, if my mouse is over the scrollable node, it invokes the Google Chrome window zoom (so I end up with two competing zoom transforms). It also zooms relative to the upper left corner, rather than relative to my cursor (seems the app doesn't support panning?). The background dots also move and change size as I zoom (subtle but somewhat distracting).

Encoding for each scenario can be quite complex unfortunately. Django does have some template filters to help.

I recommend following the documentation carefully, and using a JSON API or other similarly standard mechanism if the documented options are insufficient.

Simple JSON encoding alone is not sufficient if you put the output into a <script> tag.

<script>const user_input = "</script><script>alert(1)//"; ...

The "How to use a Python variable in an external Javascript (Django)" examples are likely vulnerable to an XSS attack, when the variable contains user supplied content.

It's important to output-encode for the correct context. By default, Django encodes template variables for an HTML context, which can allow XSS when output inside a script tag or as a JavaScript file.

Further, security of a marketing site tends to be lower priority than the product itself, and an install script should generally be secured similar to the product.

NPTv6 is different from IPv4 NAT and doesn't really have the same issues.

A different solution I've seen proposed for networks with multiple ISPs is to advertise both public prefixes to the network and let each client endpoint figure out which egress to use. This seems like a worse idea though.

The most official approach is to get your own public IPv6 prefix and work with your ISPs to BGP route that to you on both links. However, home and small business ISPs generally don't offer this.

Have you implemented NPTv6 before? What routing product(s) have you implemented this with? Do you happen to have some documentation links handy?

In my experience, this capability is missing from most off-the-shelf solutions, and in the cases where it is available, the documentation of this feature is missing or incomplete.

If you put your webcam behind your video chat window, you can achieve better eye contact with your remote participants. I wonder how well a webcam can see through these screens and/or how much of a hole would be required in the rendered image to avoid obstructing the camera.