Session issue with problem editor #2394
Comments
|
I can't reproduce this with #2391 either. |
|
Easily more than 20+ times. I just kept clicking. |
|
This is happening for me on The server is behind a firewall and I access it on PCC's internal network after activating a VPN client. It's name is I go to the problem editor. I check in on cookies, and I have two at the moment. One of size 1460 (I think for the admin course) and one of size 1468. I type
The "1468" cookie is now gone. Now if I navigate anywhere, I find that I'm logged out. So I log in again. I try the same steps and this time I get bumped off after just 10 tries. I try pretty much the same thing on the production server (where it's not behind a firewall) and the same thing happens. Although in fewer tries than 17. Now I'm in the developer tools, Network tab. Corresponding with each successful click of "Check Answers" there are two POST method entries: But then on the click of "Check Answers" where it fails, it's different: |
|
I did some testing, and although I can not reproduce this still, I think that this is not the same issue as the cookie size issue causing the header size limit to be exceeded. The message that you are getting is different. The issue may still be related to the header size limit issue, but something is clearly different. I logged into five courses which puts the combined cookie size for the domain high enough to make the header exceed the limit. Then I clicked check answers in the PG editor. Rendering fails as expected because the header size is now too large, but the message that is shown is The request size shown in the Network tab of the developer tools is consistent with the request getting truncated because of a request exceeding the size limit. This baffles me. There is no reason that the size limit should affect this. The cookies don't grow in size as more requests are made. The timestamp and cookie expiration are updated with each request, so you will see the cookie change, but the size should remain rather close to the same. I guess, you should try with #2391, and see if that changes anything. |
|
I also can't reproduce this on develop on my development machine. I'm guessing this was with session_cookies setting for session management. I check both this and the "key" method. |
|
So I tried with #2391. And believe it or not, that makes things worse! Without #2391, it consistently takes 17 clicks for me to get booted. With #2391, it only takes 10 clicks. With #2391, I see something that I did not see before. Now when the I get to the last two POSTs when I am booted off, I see this in the Network developer tools: 
You can compare that to what I posted before. The successful ones now look like: 
So now those successful ones are a lot smaller in the Transferred column, and about the same size (one a tad up, one a tad down) in the Size column. I'm not in the exact same course I was before (which was now deleted) so a small difference might just be because of the course name being different. FWIW, I also get this behavior with Chrome. The above was with Firefox. (I saw some postings about a FF bug involving NS_ERROR_NET_RESET, so I decided to try Chrome too.) It seems worth pursuing this as an issue with our local load balancer setup. I'll bring this up with our team here and see if they have thoughts about it, or even better, know exactly what would do this and can toggle something with our setup. |
|
Interesting. Note that the "Transferred" column is the only one that should have an essentially different size with develop versus #2391. That size includes the cookies. The "size" column is only the response size, which should be essentially the same regardless of if you are using develop or #2391. In fact, in my testing using the same course for both, the "size" column is identical, but the "Transferred" column is considerably smaller with #2391. Here is what I see for successful requests. The first is the padded session from develop, and the second the unpadded session from #2391.
Now when I previously tested this I tested it locally with morbo, and on a development server (with a production setup) that is serving directly via hypnotoad. So now, I tested it on my local server proxied via apache2 via my ddns. And hello, we have a problem. With the develop branch it happens after 17 "Check Answers" clicks, and with #2391 it happens with 10 "Check Answers" clicks. So this is not your load balancer. It is a more general issue when hypnotoad is proxied (which the load balancer is a form of). Now that I can reproduce it I will see what I can do to fix it. |
|
By the way, I don't see the |
|
Here is another thing to test. Go to one of the other places that a problem is rendered via the |
…k Answers" in the PG editor. It seems that if the problem rendering request does not complete before the request to save the temporary file is sent, the streams can get crossed. We all know how bad that is! This seems to only occur when proxying hypnotoad in some way or another. Somehow hypnotoad manages to keep the streams straight when proxying is not involved. Also, don't add the `passwd` and `key` to the form when rendering via the `render_rpc` endpoint unless cookies are disabled for the request, and in the case that `session_management_via` is "session_cookie" don't add the key to the form. This fixes issue openwebwork#2394.
…k Answers" in the PG editor. It seems that if the problem rendering request does not complete before the request to save the temporary file is sent, the streams can get crossed. We all know how bad that is! This seems to only occur when proxying hypnotoad in some way or another. Somehow hypnotoad manages to keep the streams straight when proxying is not involved. Also, don't add the `passwd` and `key` to the form when rendering via the `render_rpc` endpoint unless cookies are disabled for the request, and in the case that `session_management_via` is "session_cookie" don't add the key to the form. This fixes issue openwebwork#2394.
…k Answers" in the PG editor. It seems that if the problem rendering request does not complete before the request to save the temporary file is sent, the streams can get crossed. We all know how bad that is! This seems to only occur when proxying hypnotoad in some way or another. Somehow hypnotoad manages to keep the streams straight when proxying is not involved. Also, don't add the `passwd` and `key` to the form when rendering via the `render_rpc` endpoint unless cookies are disabled for the request, and in the case that `session_management_via` is "session_cookie" don't add the key to the form. This fixes issue openwebwork#2394.
…k Answers" in the PG editor. It seems that if the problem rendering request does not complete before the request to save the temporary file is sent, the streams can get crossed. We all know how bad that is! This seems to only occur when proxying hypnotoad in some way or another. Somehow hypnotoad manages to keep the streams straight when proxying is not involved. Also, don't add the `passwd` and `key` to the form when rendering via the `render_rpc` endpoint unless cookies are disabled for the request, and in the case that `session_management_via` is "session_cookie" don't add the key to the form. This fixes issue openwebwork#2394.
In develop, if I clear cookies and then log in and go to the PG editor, I can:
pias the answerBy my count on the 17th time, my session is killed and I have to log back in. This was noticed when exploring openwebwork/pg#1050.
Maybe this has to do with #2391.
The text was updated successfully, but these errors were encountered: