Files
edx-platform/openedx/core/djangoapps/user_api
Florian Haas 26281cbe36 Fix profile image URLs for image storage on non-public S3 buckets
In image_helpers.py, the _get_profile_image_urls() method would append
"?v=<version>" to the query string for serving profile images.

This might break serving profile images if

* EDXAPP_PROFILE_IMAGE_BACKEND was configured with its class option
  set to django.storages.s3boto3.S3Boto3Storage (or its deprecated
  predecedessor, django.storages.s3boto.S3BotoStorage), and
* that backend used signed URLs with query-string authentication (i.e.
  was *not* configured with an S3 custom domain).

When both the above conditions are met, then the URL returned by the
storage backend's url() method already contains "?", and
_get_profile_image_urls() would add another. This results in a query
string that doesn't exactly violate RFC 3986, but is discouraged by
it.[1]

Amazon S3 itself may be able to parse these query strings correctly,
but other S3 API implementations (such as Ceph radosgw[2]) may not,
and the problem is easily avoided by just looking for "?" in the
rendered URL, and using "&v=<version>" instead if we find a match.

The proper way of appending the v=<version> query parameter would
probably be to pull the URL and the query string apart and then back
together[3], but that's most likely overdoing it.

[1] https://tools.ietf.org/html/rfc3986#section-3.4 says:
"However, as query components are often used to carry identifying
information in the form of "key=value" pairs and one frequently used
value is a reference to another URI, it is sometimes better for
usability to avoid percent- encoding those characters." ("Those
characters" being "/" and "?".)

[2] https://docs.ceph.com/docs/master/radosgw/s3/

[3] https://docs.python.org/3/library/urllib.parse.html
2020-07-06 11:09:16 +02:00
..
2019-12-30 12:25:38 -05:00
2019-12-30 10:35:30 -05:00
2019-12-30 10:35:30 -05:00
2019-12-30 12:25:38 -05:00
2019-12-30 12:25:38 -05:00
2020-01-30 16:36:02 +05:00
2020-03-12 14:22:52 +05:00
2019-12-30 10:35:30 -05:00
2019-12-30 10:35:30 -05:00
2019-12-30 10:35:30 -05:00
2019-12-30 12:25:38 -05:00

Status: Active

Responsibilities
================
The user_api app is currently a catch all that is used to provide various apis that are related to the user and also to features within the platform.

Intended responsibility: To manage user profile and general account information and to provide APIs to do so easily. This includes the following features: user preference, user profile, user retirement, and account activation/deactivation.

Direction: Decompose
===============
Currently this app is a catch all for many user related information even when that information should really belong in a different app.  If you are building a feature and need to provide information about a user within the context of your feature, you should localize that API to your feature and make your assumptions about what user information you need clear.

For example authentication related APIs have already been moved to the user_authn django app.

Glossary
========

More Documentation
==================