-
Notifications
You must be signed in to change notification settings - Fork 213
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
AFS Submit Script Broken #126
Comments
The unofficial_submit is now a route for autolab, so I think the problem is that the example submit script needs to be rewritten, but I'm not 100% sure that everything else is working. |
We really want to fix the issue asap -- I see it bothering lots of students in 15-122 working on Windows... They should be able to run
|
The "handin" file is actually /afs/andrew.cmu.edu/course/15/122/bin/handin, which calls /afs/andrew.cmu.edu/course/15/122/bin/handin/autolabSubmit-master.sh, which follows the following protocol: Queries: https://unofficial.fish.ics.cs.cmu.edu/officialSubmit.rb?course=15122-s15&user=rjsimmon&assessment=scavhunt I'm happy to hack my script, but I just don't know a lot of things, starting with what my source number is: "15122-s15" and "14" both give me "invalid course". |
This can't be resolved until we fix our SSL setup: unofficial submit needs to use HTTP to get around the user needing HTTPS certificates, but our current Apache setup always forces HTTPS. We should be switching to Rails-enforced SSL instead of Apache, which will let Rails not force SSL for some routes. Then we can rewrite this script. |
Hi @robsimmons, I'm working on fixing this as soon as possible. The unofficial route is working now, but the url is different. It's the part of the app now, so it can be reached through: I'm not exactly sure about the expected behavior of officialSubmit and the code is pretty poorly documented at this point. Do you know of a way for me to debug this? I think I cleaned up the code but currently don't know of a way to test it. Any help and input would be great! |
Is this pushed? https://autolab.cs.cmu.edu/courses/14/assessments/49/[email protected] gives me a DK
|
@robsimmons Nope, we wanted to test it first. The pull request is still open: #163 |
More complete testing suggestion, though it's relative to prod because that's all I see. Is milkshark dev, or is it an exact alias of autolab.cs? If you're an account that's registered for 122: https://autolab.cs.cmu.edu/courses/14/assessments/49/unofficial_submit?user=${{YOUR_EMAIL}} and you should probably end up with one point. |
Also I can work on this in my office on this from like 12:30 to 1:30 if that would be useful and if anyone wants to drop by then. |
Thanks @robsimmons! Firstly, to prevent future confusion, official_submit and unofficial_submit are different things. We use I fixed the error codes and checked out to that branch on production. So you can see it now. If you go to: https://autolab.cs.cmu.edu/courses/14/assessments/49/[email protected], you will get a handin directory. I also needed to make some changes to the directory structure since we're trying to get rid of the Andrew dependencies. Currently it looks like this: 15122-s15/scavhunt/handin/[email protected]_remote_handin Is this fine with you? I'm open to suggestions here too. I'm working on the &submit= part now. It might take a little longer to fix and test. I was wondering if that request is a GET or POST. I believe that POST request would be more appropriate for the second one. |
If you're doing a file upload on the submit call, it will need to be POST, but the first call can be a GET. What if the routes were 'command_line_submit' and 'logger_submit'? |
My shell script just wgets urls, so GET is waaaayyy easier. Am I correct in understanding that there's actually some secretly-AFS-prefix I need to attach to the beginning of I think of "official_submit" as a "local" submission process - for when the user happens to have filesystem-local access to the autolab server - so I was going suggest "local_submit" myself. |
Thanks Daniel! If I'm understanding things correctly, students need |
Oh, and to be clear: can you tell me what the secretly-AFS-prefix is because I don't know it :-) |
"Places the handin tarball (handinscavhunt.tgz) in that directory" So you actually And yes, 15122-s15 is located in |
I'll just say that it's bad practice for HTTP GET requests to alter state. GET and HEAD are only meant for information retrieval. That said, if it's really that much of a pain and we're not uploading any files, GET is doable. |
POSTing a file with
I don't know what the scripts that use our route look like or how intricate their |
One concern - are there security precautions in place to prevent a user On Thu, Jan 22, 2015, 12:54 PM Jake Zimmerman [email protected]
|
I'll give it a try if you want to do the correct thing and make one of both of the protocol things a POST request. (Would you say the first request creates state by creating a directory?) I think I understand the fragment of the script that 122 is using pretty well if you can explain the actions that it is supposed to take. |
I currently see
even after I visit https://autolab.cs.cmu.edu/courses/14/assessments/49/[email protected] |
@namanbharadwaj In theory the old directories could be access-locked to the individual who had the right to handin, since there username was the same, though I have no idea whether this, or security-via-obscurity-and-the-absense-of-race-conditions was the order of the day. It would certainly make sense to limit this to andrew.cmu.edu email addresses and lock writes to the andrew id... probably the new system shouldn't be less secure than the old system if that used to be the protocol. |
@namanbharadwaj That's what I've been concerned about, but I don't think it will be any less secure than before, if that's saying anything. I think @robsimmons makes a good point that this should be CMU-specific until we can think of a less hacky solution. |
I actually see the directory: fs listacl /afs/cs/academic/autolab/autolab2/courses/15122-s15/scavhunt/handin/[email protected]_remote_handin |
This might not be the best short term solution, but I see Git-based submissions where users can upload public keys (similar to GitHub) as being a viable long-term option for all command line submissions, CMU or otherwise. |
Hmm... what are the file permissions for parent?
|
That's interesting. I'd expect you to have permissions for '/afs/cs/academic/autolab/autolab2/courses/15122-s15/' since you've been uploading the assignments etc. there. Are you on a school computer? Did you try doing |
Just pushed more changes. (We're getting there!) The route is local_submit now. The second request with |
In the old system, the directory used to be: "/afs/andrew.cmu.edu/scs/cs/autolabEmail/handin/" + users's email How did you prevent users from seeing each others' submissions? |
I have two suggestions:
|
Apparently Autolab automagically handled the permissions, which your suggestion wouldn't allow. Your solution also has the problem of being unable to ensure Autolab has access to the appropriate directory.
|
Also, option 2 is terrifying because none of these HTTP requests include any authentication. So option 2 is much less secure than whatever the old system did, which was apparently a reasonably secure thing! |
By the way: if this is the way it has to be for now, I think I can make do with this as it stands by making the script do the right funky AFS cross-domain registration stuff. I just have to give students "l" AFS permisison to a lot of stuff that I'd really like them to not have any access to. |
Students shouldn't need "l" rights on a parent directory in order to write On Thu, Jan 22, 2015, 2:26 PM Robert J. Simmons [email protected]
|
I didn't think that was true, @namanbharadwaj. If I take [email protected] off of academic:admin.15122 I can't access that directory anymore
|
(off topic) ...all my email addresses are going to be harvested off of this issue thread for the rest of time... |
Okay, so some things. Giving myself enough AFS permission that I can actually access the relevant directory again, I managed to play the game successfully by hand. Yay! I could turn this into a submit script:
But it didn't grade on autolab (and is incidentally ugly): And going to "regrade" DKs:
This exposes another problem: the .tgz almost certainly need to be copied into the autolab handin directory as a regular submission, not left in the student-writable directory! (!!!!!!) Otherwise they will overwrite their handins the next time they submit, removing Autolab's (very useful to students, in a pinch) utility as a last-ditch version control system its utility (critical to me as an instructor) as a trustworthy and immutable recordkeeping of student submissions. |
Hi @robsimmons, I've fixed the problem with the file name and location. As for the permission, Autolab actually still automagically handles the afs permission. It gives the student rlidw permission to the director.
I also realized that adding Can you test this and let me know? Everything seems to work for me. |
I can see that I correctly have permission to /afs/cs.cmu.edu/academic/class/15122-s15/autolab/pixels/handin/[email protected]_remote_handin but I don't have "l" permission to the parent directories (which I really do think I need, @namanbharadwaj) so as long as I have taken [email protected] off of academic:admin.15122, I can't copy to that directory. It seems to work if I add [email protected] back to academic:admin.15122, so we just need to figure out directory access and we're in business. Is there a barrier to having the handin directory be andrew-side and leaving the complicated cross-domain bits to Autolab? |
I see. I just realized that it was working for me because I'm in autolab group... Sorry for that! In this case what I'm planning to do is letting the instructor define that directory, so instead of hardcoding |
Okay - I can probably make that work, even if it's in the CS domain. Even better would be if the instructor-defined path could be in the andrew domain, but if that takes longer to get working then just do the cs thing. |
So I created the variable and added as a setting. Under 'Edit Assessment > Handi', you'll see the Note that you no longer need to add the prefix of |
Sounds good! Will that path be set as a default? I'll poke at this in the morning. |
It's not default, but we can do that if you'd like. Also, I think you can get this to work on Andrew domain if you really don't want the CS domain. I just didn't know what path to use on andrew. |
You currently have it working on the Andrew domain! |
Thinking a bit more about paths: is what we want in general a course specific prefix followed by an (optional) assignment specific section? That way, the configuration you had before makes sense (course prefix: |
Good point! I just pushed that change. The setting is still assessment based since I didn't want to move it to class settings, but the sub directory is called |
I can't imagine why this doesn't appropriately belong in class settings, but I guess you're the dev. I think I can produce a working script with this, working on that now. Three requests:
|
You can use "https://autolab...." instead of "https://autolab..." this should solve the problem with the certificate. We have plans to add the course name to the url, but I'm not sure about the timeline. |
All the changes are merged to master. |
We never made an issue for this but it was discussed here: we just merged a patch to add course names to URLs. We'll be rolling it out soon, but we'll make sure to give people enough time to change links. The unfortunate thing is that the two schemes aren't compatible with each other. Reference: #424 . |
The example script given (
Autolab/script/autolabSubmit.sh
) is broken. In particular, it seems that theunofficial.fish.ics.cs.cmu.edu
URL can't see "new Autolab" courses and gives meERROR: invalid course
.15-210 uses this for all labs, so getting a fix for this or a new URL that works would be nice.
The text was updated successfully, but these errors were encountered: