Merge TENET and REANNZ work + upgrade deps #107
Conversation
madsi1m
commented
Jan 6, 2025
madsi1m
commented
- Merge work by @ghalse from TENET
- Merge work by @Razorfang from REANNZ
- Also some other deps updates
* Notes about when changes are deployed * Clarify when we want IP vs hostname * Sanity check shared secrets * Try reduce spurious registrations by explaining who can use * s/CAT/geteduroam/ * Warning about enterprise passwords
Add EAP-TLS, EAP-PWD Allow EAP-GTC to be used for monitoring
Extend the YAML output from the servdata command to include the two missing pieces of data from the current model: proto and addr_type. The latter is useful when one wants to provide the option for IPv6 support in a RADIUS server that supports it.
RFC2616 states that HTTP headers are encoded in latin1 (iso-8859-1), and the Python/Django request.META (correctly) assumes that incoming headers will be encoded in this way. However, by default, Shibboleth ignores the iso-8859-1 restriction and puts the UTF-8 encoded values from SAML into its request headers with ShibUseHeaders without transliteration [ref](https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334723/ContentSettings)]. This results in incorrectly encoded characters when non-ASCII / accented characters are used in e.g. the first or last name. There are two ways we could fix this. The approach used here is to simply acknowledge the incorrect encoding and fix it (i.e. force the string to be interpreted as UTF-8 rather than Latin1. This is backwards compatible and will be invisible to any sites that don't already have incorrectly encoded names. The alternative would be to make use of Shibboleth's `ShibRequestSetting encoding URL` option in the Apache config to force Shibboleth to URL encode the string. We would then have to decode it when we consumed it. This approach is arguably more correct since the headers would be RFC compliant, but involves much more work and requires users change their webserver config. It's not backwards compatible.
bump Mako and requests as far as python 3.7 will go
|
While I think that some of my commits included here are generally useful to others, some are already the subject of other pull requests:
There's also at least one that's very specific to our use case, and is probably not generally applicable: Arguably that's true of 0ce042c too, but its at least generic enough that it won't confuse anyone. |
|
Hey there, I'm Jamie Getty from REANNZ. This is my first time talking here since I've only been with REANNZ for around six months. My commits shouldn't be here. They're part of a project I'm working on to try and update the Django version to one that's actively supported. I am currently working on a fork of this repo and I'll open a pull request when my changes are done, but for now, they should not be used. |
|
Thanks for the info @ghalse and @Razorfang, I've been trying to gather the best mix of djnro and this is what i came up with for our site, for the moment. @ghalse as the important changes already have seperate PRs I will close this. @Razorfang I was considering a Django upgrade, as Vlad mentioned it should happen at some point. Happy to hear that you are on it and am looking forward to it, Please let me know if you require another site to do some testing :) Once again, thanks both on your efforts, keep up the good work 👍 |
|
Vlad is on leave until 21st January so if any more REANNZ questions come up before then, ask me. |
3 participants
