Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running in a subpath is not supported #490

Open
ralokt opened this issue Aug 25, 2020 · 1 comment
Open

Running in a subpath is not supported #490

ralokt opened this issue Aug 25, 2020 · 1 comment

Comments

@ralokt
Copy link

ralokt commented Aug 25, 2020

I'm trying to host the LRS in a subpath, ie, it is to be accessed via <domain>/lrs.

This appears not to be supported - for semi-technical/political/bureaucracy reasons, running on a subdomain is not an option for me.

Issues I ran into so far:

  • STATIC_URL and MEDIA_URL are not configurable via settings.ini. This isn't a huge issue, it's trivial to set DJANGO_SETTINGS_MODULE manually and then define custom settings that import and overwrite the default settings.
  • /me shows wrong endpoint. This is what prompted me to create this issue, since it's not circumventable with creative configuration. This template code [1] assumes that it can generate the endpoint like so:
http{% if request.is_secure %}s{% endif %}://{{ request.META.HTTP_HOST }}/xAPI/

A possible fix for this particular issue would be to use URL reversal here (and give this pattern [2] a name to make that possible).

This list is not exhaustive since I have only begun my deployment in a subpath, and am therefore only able to report my findings so far.

It would be great if in general the LRS didn't make this assumption about how it is deployed, however.

[1] https://github.com/adlnet/ADL_LRS/blob/master/adl_lrs/templates/me.html#L30
[2] https://github.com/adlnet/ADL_LRS/blob/master/lrs/urls.py#L8

@vbhayden
Copy link
Member

Hey there! I don't think the original team accounted for that situation, although it's a pretty common pattern in our age of containerized proxies.

Agree that the more flexible this can be, the better. I'll skim through this week and check a few ideas (including yours) to see if we can support this.

Thanks!
-Trey

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

No branches or pull requests

2 participants