Unsupported Method Post

I’m trying to get STATA to work on OOD 1.7 where I work. I’ve had several issues. The latest is when I tried to copy the config for an existing NoVNC Desktop image to see if that works and got this 501 Error mentioned above.

I’ve got a screenshot:

Shared with CloudApp

Hi and welcome!

@travert please advise.

Hi @DChandlerP,

Would it be possible to see the config you are currently trying to use for this?

@travert

I can share more but not the whole repo I’m working in because it’s, unfortunately, tightly coupled to the config of the entire cluster stored in Ansible.

@DChandlerP It looks like your form is POST’ing to the noVNC URL, with the current implementation of noVNC in OOD POSTing to the noVNC client view won’t work. noVNC authenticates sessions using the query parameters associated with the request.

Here’s where the noVNC link is generated on the server side and the query parameters (password and path) are set here:

In your screenshot where does the /auth-do-sign-in path come from? Can you share your reverse proxy config from ood_portal.yml:

host_regex: '[\w.-]+\.my_center\.edu'
node_uri: '/node'
rnode_uri: '/rnode'
host_regex: '{{ ood_regex_basestring }}'
node_uri: '/node'
rnode_uri: '/rnode'

Our base string:

ood_regex_basestring: 'compute1-exec-[\w.-]+.ris.wustl.edu'

Looking at the ood_regex_basestring I don’t see the 1 at the end of compute in the URL. Does anything change if you use something like:

ood_regex_basestring: compute-[\w.-]+.ris.wustl.edu

I couldn’t get any jobs to land on the test cluster after I made those changes. I’m not sure if it’s because of this change. I may have to try it again tomorrow both with and without these changes.

I was finally able to apply the changes. I’m still getting the same error:

Shared with CloudApp

Sorry it still isn’t working. Would it be possible to use your dev tools to send some more information? Just press F12 in the browser (same for FF or Chrome) then select the Network tab at the top.

After you have that open, go to the submit page for setting up the STATA app and submit as usual. There should be quite a bit of information in the panel that shows up, but the status 500 is what will be of interest.

If you could send a screen shot of headers form the dev tools network panel for that request it would likely help in tracking down what is not configured correctly.

I know about how to use Developer Tools to some degree, but I’m not quite sure what you want.

Shared with CloudApp

I press that “Connect to Stata Server Button”. It always opens a new tab where I get that error. That new tab doesn’t give me much helpful. Even in the Network tab:

Shared with CloudApp

Thank you for taking the time to do that and posting the screenshot.

Looking at this it is odd to see that auth-do-sign-in.

Would it be possible to see the view.html.erb that you are using. Other apps do have this set in the view.html.erb so it may have been from a copy-paste error of some kind. But the view.html.erb would be the likely culprit forcing that url to be hit incorrectly when you hit the connect button.

This one doesn’t have one per the github link I provided earlier. It’s highly derivative of another app we have that doesn’t use one… but which does work.

Ok, I didn’t see one in the repo but was hoping it wasn’t included for some reason. Very strange that this is landing you here but I can’t see anything in the configs to cause this so far.

Would it be possible for you to post the inspection of that “Connect To Stata Server” button itself? I’m curious what the input and form have set for some data.

Sorry I was a bit slow. I was switching between multiple tasks:

Shared with CloudApp

No worries, thank you for taking the time again to post the screenshot.

There’s something odd going on here with the veiw because that url and method for that app are not right.

Are you able to go into the config directory and grep? Something like:

grep -ri 'auth-do-sign-in' /etc/ood/config

And then seeing if there is some view.html.erb that has that entry.

I get no results when I search my repo for this. I could look for this on the cluster in production or development if that’s what you’re suggesting.

Yeah, sorry I didn’t make that more explicit.

Run the command on the cluster that is giving the observed behavior so we can see if something else is configured to cause this.