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
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 ==================