Use own ad server #226
Use own ad server #226
Conversation
…_location (instead of using the psiturk location)
|
Woohoo this is awesome! I'll do a code review too to help out with this as I think this is pretty important. Maybe I will do a PR after this to include integration with something like Let's Encrypt :-) |
| /* these are all the same for now, but easy to modify individually */ | ||
| #container-ad, #container-error, #container-exp, #container-consent, #container-instructions, #container-questionnaire { | ||
| position: absolute; |
There was a problem hiding this comment.
These lines were removed on purpose, so adding them back in will introduce a regression -- see #159
There was a problem hiding this comment.
@jhamrick Ah okay mb. Hmm I'll try to figure out a different way to make it match the 'push the complete button' page used when using the psiturk ad server.
There was a problem hiding this comment.
Oh I get it now. the style.css on psiturk.org, which I incorporated into this commit, is outdated. I'll just revert all changes to this file.
|
@jhamrick Code review would be great! The problem with Let's Encrypt is that they won't issue certs for IP addresses -- so domain name registration would still be required. On Fri, Apr 22, 2016 at 4:08 PM Jessica B. Hamrick notifications@github.com
|
| ) | ||
| else: | ||
| # then AMT isn't involved. Show them a thanks message and tell them to go away | ||
| return render_template( 'thanks.html' ) |
There was a problem hiding this comment.
Doesn't this still need to have the template variables like is_sandbox, hitid, assignmentid, and workerid? Unless I'm missing something here? And I'm a bit confused about the comment -- isn't this used if we're relying on the psiTurk ad server, which does still involve AMT?
There was a problem hiding this comment.
@jhamrick I admit that I'm a bit confused about the purpose of thanks.html. It was put back in 2.1.2 by @gureckis. It doesn't use is_sandbox, hitid, assignmentid, or workerid anymore (it used to, before psiturk 2.0. It used to have the "click here to submit your hit" button). I couldn't figure out a way how workers would ever get to this page if they were using AMT. If they try to revisit the ad page, AMT just says "no more hits available to you in this group" and doesn't show the ad... at least that's how it went for me. Todd said this in the commit: "local thanks page needed when reloading the local ad and a worker has already completed the task."
The only time I could see it being reached is if it were in debug (non-AMT) mode and a worker re-visited the /ad page. I guess though that /ad wouldn't be involved in debug mode.
My confusion aside, it should all still work fine though, just removing the "then AMT isn't involved" part.
There was a problem hiding this comment.
Ahh, ok, so those variables were accidentally left in even though they weren't being used. Got it. Looks good then!
|
Ahh, good point. Bummer. Well, it might still be worthwhile to do if you are running psiTurk behind a domain name (which I usually am). |
|
Oh one additional comment is that since you are adding in new config options, it would be good to add those to the relevant documentation files too: |
|
@jhamrick right, good idea. My original thought was to not document this until it had been tested a bit -- like the "experimental tunnel server" was never documented. But since things are going into the default config file users will wonder about them. I'll document it. Also a github noob question -- do I have to do username mentions each time for you to know that I responded since you're not the thread author? Or would you get notification regardless? . Thanks a ton for the code review. |
|
Ah, I see. I would probably err on the side of documenting it and maybe just adding a note to say it's an experimental feature rather than not documenting it at all.
Once someone comments on a thread they get notifications by default, so it's not necessary to @-mention people. If they haven't commented yet, though, then @-mentioning them will notify them (unless they are already automatically subscribed to all issues on the repo, in which case they'll get notified regardless). The one thing that doesn't get notified is if you push a new commit to a PR that addresses someone's comments -- in that case you want to leave a comment saying you've made the changes. No problem for the code review! Glad to help on the occasional chance that I have a few spare moments 😛 |
…m back in will introduce a regression -- see NYUCCL#159". This means that the `style.css` on psiturk.org, which I incorporated into this commit, is outdated. I'm reverting all changes to this file.
….html' more clear
…hit_create less bulky
|
@jhamrick code commits done, working on docs now. I'm going to pull all the commentary out of the default config file. After looking at it again, it may be overwhelming to non-technical newcomers. I'll move the commentary into the docs. |
[shell parameter] SSL- and ad-server-related experimental features. Sorry in advance for typos. Also I'm removing most of the inline documentation from the default local config.txt file. It seemed like it might have been overwhelming to newcomers. I moved it into the docs instead.
|
Okay documentation pushed up now too. Phew 😴 😌 <== my first github emoji |
|
👍 looks great to me! Though note, I haven't actually tested it, just looked through the code. GitHub emojis are the best! 🎉 |
…abled, a proxy server must be used in front of it in order to serve static content.
|
Todo:
Scratch this, it's not clear to me that the functionality of |
…mpting to load when using own ad server but debugging
|
I am having issues setting up my own ad_server. I followed this gist to set up the psiturk gunicorn server behind an nginx, with SSL enabled through Some key configurations:
I also tried running gunicorn with SSL by 1. uncommenting the above two lines for SSL keys in |
|
Either things have changed a bit in nginx, or my gist was always wrong.
Regardless, try taking out `ssl on;` and adding `ssl` to the listen line,
like this: `listen 443 ssl;`.
Also, for good measure, specify the ssl protocols to accept in the nginx
server block, like in here:
http://nginx.org/en/docs/http/configuring_https_servers.html
…On Wed, Jan 9, 2019 at 5:29 PM Hörmet Yiltiz ***@***.***> wrote:
I am having issues setting up my own ad_server. I followed this gist
<https://gist.github.com/deargle/5d8c01660a77b8090a2cd24efcda2c59> to set
up the psiturk gunicorn server behind an nginx, with SSL enabled through
certbot serving at port 443. I am getting the following SSH error from
mTurk once I fill in my AWS and mTurk API keys (both of which work if used
directly from within psiturk in sandbox mode, not behind nginx).
The error message:
ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:727)
Some key configurations:
# config.txt
[Server Parameters]
host = 0.0.0.0
port = 22362
# certfile = /etc/letsencrypt/live/exp.myserver.com/fullchain.pem
# keyfile = /etc/letsencrypt/live/exp.myserver.com/privkey.pem
[Shell Parameters]
launch_in_sandbox_mode = true
use_psiturk_ad_server = false
ad_location = https://www.myserver.com:443/ad
# cat /etc/nginx/sites-available/psiturk-host-own-ad.conf
# use this if you're hosting your own ad (i.e., you're not using the psiturk ad server). Requires that you have your own ssl cert.
server {
listen 80;
server_name www.myserver.com www.myserver.com;
rewrite ^/(.*) https://www.myserver.com/$1 permanent;
}
server {
listen 443;
root /mnt/home/hyiltiz/src/myexp;
ssl on;
ssl_certificate /etc/letsencrypt/live/exp.myserver.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/exp.myserver.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
server_name exp.myserver.com;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location / {
# checks for static files; if not found, proxy to app
try_files $uri @proxy_to_app;
}
location @proxy_to_app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://localhost:22362;
# proxy_pass https://localhost:22362;
}
}
psiturk can create hit in sandbox mode without using the nginx reverse
proxy, or nginx can serve the experiment correctly at
http://exp.myserver.com (which redirects to) https://exp.myserver.com
when no AWS and mTurk keys were provided in ~/.psiturkconfig file. That
is, the keys were wroking and the SSL were working, but mTurk doesn't like
the ad_server that I set up here.
I also tried running gunicorn with SSL by 1. uncommenting the above two
lines for SSL keys in config.txt, 2. use proxy_pass
https://localhost:22362; in nginx configuration instead, 3. restart nginx
and start psiturk. That threw the same errors as well.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#226 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABHsfYirj-PZ9uJzXlc18ab1TM_bN1xMks5vBolegaJpZM4IN6xL>
.
|
|
Removed I see no reason to do Somehow getting mTurk to accept our nginx server is not working. Is there a working documentation for how to set up |
You and I are updating the documentation right now ;-) I wrote all that functionality, and the gist.
Agreed. One user needed ssl all the way, even between the rev proxy and gunicorn, so I added that for him. But it's not necessary for mturk.
I hope you meant Consider letting heroku host your stuff. They give you rev proxy and ssl out of the box. I wrote a doc page for that somewhere on readthedocs. I am guessing that the error has something to do with mturk expecting the nginx server to support a different cipher suite -- probably tls 1.3. Try adding that. like this |
|
Yup, it was 443. Was a typo. Same error with The error trace above wasn't quite helpful, so here is an Just noticed that even commenting out I am getting the same error with my experiment or using the psiturk example experiment. |
Okay here goes. This is functionality for toggling the use of the psiturk ad server. Look in the new comments in psiturk/default_configs/local_config_defaults.txt for an overview of the changes. See this gist for an example config. Here's a summary of the process:
true.ad_locationurl in the config for the location of your psiturk ad route. This url should point to a proxy server running in front psiturk/gunicorn. I used nginx. See the gist referenced above for a config that works for psiturk (and for flask/gunicorn/nginx in general). Your proxy server will need to handle SSL. You will need to get your own certs right now if you want to do this.keyfileandcertfilein the[Server Parameters]section. Assuming your process has permissions necessary to read the keyfile, they'll be loaded into gunicorn (see the same gist as before for an example of launching psiturk with sudo while still using the proper virtualenv binaries). If you do this, make sure that you switch the url of your proxy_pass in nginx to use thehttps://protocol.Some other changes:
closepopup.htmlfrom the dead. Also bringing back the oldthanks.htmland calling itthanks-mturksubmit.htmlso that it has the nice submit button thing. Leaving the 2.0thanks.htmlalone.Even if this isn't merged, it demonstrates how to go about the process.
Also see #121