Failure loading job


#1

In going in to edit an existing job in the job com[poser, when I try to edit th script for my slurm job, I get the following:

Failed to load file!

The file failed to load. Please try again later.

/home/wew/ondemand/data/sys/myjobs/projects/default/2/lazyjob.sh


#2

Do you know what the permissions are for /home/wew/ondemand/data/sys/myjobs/projects/default/2/lazyjob.sh?


#3

Yes,
-rw-r–r-- 1 wew clusteradm 662 Oct 26 15:08 lazyjob.sh


#4

If you open dev tools or console in your browser do you see any JavaScript errors? The editor app does an AJAX request to load the content.


#5

I see this in the console: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cas.nau.edu/cas/login?service=https%3A%2F%2Fondemand.hpc.nau.edu%2Fpun%2Fsys%2Ffiles%2Fapi%2Fv1%2Ffs%2Fhome%2Fwew%2Fondemand%2Fdata%2Fsys%2Fmyjobs%2Fprojects%2Fdefault%2F6%2Fmain_job.sh. (Reason: CORS request did not succeed).


#6

As a note this is running under firefox on Macos Sierra. The job was created from a template I used to see the contents of the script and not it is just showing a link to the name of the shell script. Is there a way to attach screenshots?


#7

You can drag and drop images into the editor.


#8

I’ve seen this before. The file editor loads the file to edit using an AJAX request. The AJAX request is getting blocked because you are logged out - or it thinks you are. I’ll see if I can reproduce this error here tomorrow.


#9

Sorry for late response on this. Haven’t had a chance to try to reproduce this yet. The main problem of course, is that you are authenticated, but the AJAX request is not being recognized as being authenticated, so it is being redirected to the CAS server to login (or verify login) and since its an AJAX request with the source of ondemand.hpc.nau.edu the case server then rejects it because it is a Cross-Origin Request.

The AJAX request for the file editor is setting this header which is supposed to help with this: X-Requested-With: XMLHttpRequest.

So I’m not sure yet what the next steps are.


#10

@wew can you still reproduce this defect? If so, it is possible the defect is related to this mailing list post:

https://listsprd.osu.edu/pipermail/ood-users/2019-January/000346.html

In it @ddietz discusses a situation where a request is being redirected to the CAS server for authentication because the CAS Scope being written to the cookies. His solution was to move the authentication directives to a single location directive section <Location "/"> including, I believe, 'CASScope /'.