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

support url prefix instead of just top-level #425

Open
rmaronson opened this issue Jun 8, 2020 · 5 comments
Open

support url prefix instead of just top-level #425

rmaronson opened this issue Jun 8, 2020 · 5 comments

Comments

@rmaronson
Copy link

rmaronson commented Jun 8, 2020

We have the use case where we have one public domain name as entry point to our lab resources, but we'd like to be able to use multiple studies. We have nginx set up to reverse-proxy to different instances of psiturk to enable different, unrelated experiments but it's not clear how to make studies differently addressable from outside. The easiest way to map to different locations would be to use an alternate path, i.e.

studies.mylab.univ.edu/study1/ -> study_computer:22311
studies.mylab.univ.edu/study2/ -> study_computer:22312

Unfortunately, the links within the files refer to top-level locations, so this fails (i.e. "/sync"). (Note that because of our setup, it's not easy to add additional subdomains nor open additional ports.)

Suggested resolutions:

  • Make all links relocatable by removing all leading / (e.g., /sync/ -> sync/), then the links will be interpreted relative to any top level directories
  • Add a prefix option to the config file that gets supplied to each url which gets resolved in the templates and python init, similar to the url_prefix option in Blueprint

I am happy to do this + add a PR if there is resolution on what the right approach is, but no promises that I'll be able to track down all the urls in the first pass :)

@deargle
Copy link
Collaborator

deargle commented Jun 8, 2020

Hmm let's find all hardcoded urls first and document them here, then think about the different needs of each.

I'm distracted rn, but here's a start:

@rmaronson
Copy link
Author

did a very quick scan and didn't find anything else in the py files, but inside dashboard all of */list.js included hard-coded calls to /api/xyz, and many of the html templates include those js files with absolute urls

@rmaronson
Copy link
Author

presumably the html templates could be handled with more aggressive use of {{url_for}} (like in

<link rel='stylesheet' href="{{url_for('.static', filename='style.css')}}">

not sure so much about the js. it doesn't seem like a great plan to force them to be templated if they don't need to be otherwise.

@deargle
Copy link
Collaborator

deargle commented Oct 7, 2020

I'm not opposed to the js files being templated, especially since there's already this weird thing that happens where psiturk.js is loaded as a string from here and here and then served as "static" route here

So it's already templated, basically, even if someone has already run psiturk-setup-example, they'll always have the psiturk.js that's bundled with their current psiturk version. For better or worse. Unless! Unless they copy psiturk.js into their experiment's 'static/' folder.

@deargle
Copy link
Collaborator

deargle commented Oct 7, 2020

Also, I think those /api calls will be relative to the site root, since the api gets registered as a blueprint. I'll have to look more closely at the javascript in there though.

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