Skip to content

JUN/CAMROM-008: feat: add generating QR - #241

Merged
MoisesGSalas merged 1 commit into
camrom/juniper+campusfrom
JUN/CAMROM-008
Oct 25, 2021
Merged

JUN/CAMROM-008: feat: add generating QR #241
MoisesGSalas merged 1 commit into
camrom/juniper+campusfrom
JUN/CAMROM-008

Conversation

@MaferMazu

@MaferMazu MaferMazu commented Sep 13, 2021

Copy link
Copy Markdown

This allows a QR code to be generated with the plugin and corresponds to issue CAMROM-008 from this list

@MoisesGSalas
MoisesGSalas marked this pull request as ready for review October 14, 2021 12:24
@MoisesGSalas
MoisesGSalas merged commit 58a7a26 into camrom/juniper+campus Oct 25, 2021
cruise-control-service pushed a commit that referenced this pull request Apr 20, 2022
Previously, our rate-limiting code trusted the entire `X-Forwarded-For`
header, allowing a malicious client to spoof that header and evade
rate-limiting. This commit introduces a new module and setting
allowing us to make a more conservative choice of IPs.

- Create new `openedx.core.djangoapps.util.ip` module for producing
  the IP "external chain" for requests based on the XFF header and the
  REMOTE_ADDR.
- Include a function that gives the safest choice of IPs.
- Add new setting `CLOSEST_CLIENT_IP_FROM_HEADERS` for configuring how
  the external chain is derived (i.e. setting the trust
  boundary). Currently has a default, but we may want to make it
  mandatory in the future.
- Change `django-ratelimit` code to use the proximate IP in the external
  chain -- the one just outside the trust boundary.

Also:

- Change `XForwardedForMiddleware` to use more conservative choice for
  its `REMOTE_ADDR` override
- Other adjustments to `XForwardedForMiddleware` as needed in order to
  initialize new module and support code that needs the real
  `REMOTE_ADDR` value
- Metrics for observability into the change (and XFF composition)
- Feature switch to restore legacy mode if needed

This also gives us a path forward to removing use of the django-ipware
package, which is no longer maintained and has a handful of bugs that make it
difficult to use safely.

Internal ticket: ARCHBOM-2056
MaferMazu pushed a commit that referenced this pull request May 20, 2022
Previously, our rate-limiting code trusted the entire `X-Forwarded-For`
header, allowing a malicious client to spoof that header and evade
rate-limiting. This commit introduces a new module and setting
allowing us to make a more conservative choice of IPs.

- Create new `openedx.core.djangoapps.util.ip` module for producing
  the IP "external chain" for requests based on the XFF header and the
  REMOTE_ADDR.
- Include a function that gives the safest choice of IPs.
- Add new setting `CLOSEST_CLIENT_IP_FROM_HEADERS` for configuring how
  the external chain is derived (i.e. setting the trust
  boundary). Currently has a default, but we may want to make it
  mandatory in the future.
- Change `django-ratelimit` code to use the proximate IP in the external
  chain -- the one just outside the trust boundary.

Also:

- Change `XForwardedForMiddleware` to use more conservative choice for
  its `REMOTE_ADDR` override
- Other adjustments to `XForwardedForMiddleware` as needed in order to
  initialize new module and support code that needs the real
  `REMOTE_ADDR` value
- Metrics for observability into the change (and XFF composition)
- Feature switch to restore legacy mode if needed

This also gives us a path forward to removing use of the django-ipware
package, which is no longer maintained and has a handful of bugs that make it
difficult to use safely.

Internal ticket: ARCHBOM-2056

Backported from a251d18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants