unproctored access to a new version of a proctored test #2244
Comments
|
I realized that this is actually much worse than I initially believed it to be. There are other ways that this technique can be used. One case is that the student starts the test in a proctored environment and copies the proctor username and key. Then leaves the proctored environment and goes to another computer elsewhere, and this technique can then be used to reenter the test and continue working it. The test can not be graded using this technique unless the test is set to require a proctor password on start only. Another way this technique can be used is if there are multiple proctored tests in the course. The student could start one test in a proctored environment and get the proctor username and key, and then leave and use the technique to enter and start a new version of any other proctored test in the course even while the first test has not timed out. Making the proctor key specific to the set and version will fix the second issue, but it won't fix the first. |
|
How about making the key specific to the set, the version, and also something like the IP address? Can that ever change during a session if a computer lab has some weird setup? |
|
I had thought of that to. That should mostly work. The IP address can't change, but it can be spoofed. That is certainly more challenging, and generally beyond what most hacker students attempting to cheat on a test would be capable of. |
|
It is theoretically possible for the IP address to change during a session. I can give two examples, though I can't speak to how likely they are to actually happen.
These types of configurations also raise another weakness of tying the key to an IP address: when using NAT it's possible that a large number of computers (possibly a whole campus) will appear to WW as if they are coming from the same source IP. This wouldn't break anything, but it would limit the effectiveness of this check. Also note that any IP-based filtering/security would require anyone who is using a reverse proxy to have it configured correctly so that source IPs are properly identified by WW. Can cookies be used to store this information, and does that improve anything? I realize cookies can be copied to another machine. |
|
Storing the information in an encrypted cookie is better. It is not perfect, since cookies can be copied, but it is much harder to copy a cookie than the proctor username and key. Particularly assuming that the proctor is paying some amount of attention. |
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 20, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 21, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 23, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 23, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 23, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 23, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 29, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 29, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Feb 29, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Mar 2, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Mar 5, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this issue
Mar 6, 2024
This requires another change to the `key` table. The `set_id` column has been removed, and in its place is a `session` key. This column is a JSON column and holds all session values. Note there are really two sessions that can be used. A cookie session (for this the Mojolicious session is used) or a database session. Which is used is determined by the `manage_session_via` course environment setting. The database session works by saving a hash in the stash key named 'webwork2.database_session'. This hash is saved to the database in the `after_dispatch` hook. This means that regardless of which session is used, session values can be set anytime after the session is created in authentication and before the `after_dispatch` hook is called. That is pretty much at anytime in a content generator module. Do not directly use the `Mojolicious::Controller::session` method (which will only set cookie session values) except in the authentication modules. Instead call the `WeBWorK::Authen::session` method which takes care of setting the values for the correct session type (database or cookie). One value the session now holds is what the `set_id` column stored before. In addition proctor authentication is completely reworked. Instead of the hack to use a separate proctor key, session values are used. There are some additional security measures implemented to make it harder for a student to hijack the session and gain access to a test after a proctoring session without having submitted the test as observed in openwebwork#2243 and openwebwork#2244. First, the proctor username and password (and the submit button) must come from a POST request. Parameters from a GET request are ignored for these things. It is a little harder to construct a POST request than a GET request. Second, the data saved in the session is specific to the set and version. So it is not possible for a student to open a new version of a test anymore, only to regain access to the version that was being worked. Third, the proctor_user is no longer saved in a hidden field in the GatewayQuiz form. If proctor authorization has been granted, then the authorization is saved in the session, and so the proctor_user is not needed. Some of the derived authentication modules will need some changes to work with this. Of course the LTIAdvantage, LTIAdvanced, and Proctor modules have already been changed and tested. Looking at the LDAP and CAS code, it seems that they should still work with this, but I can't test those. Most likely Cosign, Moodle, and Shibboleth will need changes. I don't know if anyone still uses the Moodle module. They really shouldn't, and should use LTI instead. I think that module should be deleted.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An issue was discovered while looking into #2243. A clever student taking a proctored test could gain unproctored access to a new version of a test, as described in that thread. Possible solution is to make a proctor_key be specific to one particular version of a test.
The text was updated successfully, but these errors were encountered: