[LON-CAPA-admin] Action : Invalid Access
H.K. Ng
hkng at fsu.edu
Mon Jan 12 11:40:08 EST 2009
Stuart,
Thanks for the fix. However, a similar problem cropped up. If a link
file such as
<link rel="stylesheet"
href="/res/fsu/PhysicsLabs/ToolBox/preLabs.css" type="text/css" />
is enclosed with a problem, the css file is not processed with the
problem when the problem link is url hidden. Not sure if the same
problem exists for to an external link to a problem.
-hk
At 03:31 PM 1/8/2009, you wrote:
>Hon Kie,
>
>Thanks for providing me with a student role in your course.
>As this bug was only affecting encrypted resources (i.e., those with
>"url hidden") in a course, I had not seen it in my earlier testing.
>
>It was an unintended side effect of the fix for bug 1736, which
>involved a change in lonmenu.pm which was in 2.7.99.1 but not in
>2.7.99.0.
>
>In LON-CAPA 2.7.99.1 the following:
>
>loncom/interface/loncommon.pm rev 1.692.2.11
>loncom/html/res/adm/pages/annotator/admannotations.pm rev 1.28.2.2
>
>fix this issue.
>
>The relevant line changes for /home/httpd/lib/perl/Apache/loncommon.pm
>
>Line 9599:
>- my ($symb) = @_;
>+ my ($symb,$delete_enc) = @_;
>
>Line 9563:
>- delete($env{'request.enc'});
>+ if ($delete_enc) {
>+ delete($env{'request.enc'});
>+ }
>
>and /home/httpd/lib/perl/Apache/admannotations.pm
>
>Lines 181-182:
>
>- my ($symb_old,$symb_old_enc) =
>&Apache::loncommon::clean_symb($env{'form.symbold'});
>- my ($symb_new,$symb_new_enc) =
>&Apache::loncommon::clean_symb($env{'form.symbnew'});
>+ my ($symb_old,$symb_old_enc) =
>&Apache::loncommon::clean_symb($env{'form.symbold'},1);
>+ my ($symb_new,$symb_new_enc) =
>&Apache::loncommon::clean_symb($env{'form.symbnew'},1);
>
>Stuart Raeburn
>MSU LON-CAPA group
>
>
>Quoting "H.K. Ng" <hkng at fsu.edu>:
>
>>Hi Stuart,
>>
>>Thanks for your response. I have enrolled you (user raeburn) in my
>>course (PHY2048C Spring 2009) as a student. Trying logging in to
>>loncapa5.fsu.edu (running 2.7.99.1) and then submit some answers for
>>any problem in the first folder and the message appears. If you switch
>>to any of the other servers, loncapa1, 2 .. , (running 2.7.99.0) the
>>answers are accepted. Here is what I can gather.
>>
>>1. Stopping and starting loncontrol and httpd in 2.7.99.1 does not seem
>>to make any difference except this time I do not get the lonhttpd not
>>running message (??). The invalid access problem persists.
>>
>>2. Reverting to 2.7.99.0 does solve the problem.
>>
>>My library server is running 2.7.99.0, if that makes any difference??
>>
>>-hk
>>
>>
>>At 04:04 PM 1/7/2009, you wrote:
>>>Hon Kie,
>>>
>>>Your second report is puzzling.
>>>
>>>loncontrol stop/start/restart in neither 2.7.99.1 nor 2.7.99.0 will
>>>report anything about lonhttpd. (This lightweight httpd daemon has
>>>been eliminated from LON-CAPA 2.8 due to institutional
>>>policies/firewall issues for non-standard ports (such as 8080, where
>>>lonhttpd listened).
>>>
>>>However, stop/start/restart in LON-CAPA 2.7.1 (and previous versions)
>>>will report actions for this daemon. That said the previous use of
>>>the lightweight http daemon to serve a number of commonly used items,
>>>such as icons etc. would seem to be unrelated to the reported "Invalid
>>>Access" error for /res/fsu/ng/mathReview/geometry/arcLength.problem
>>>
>>>"Invalid Access" is a response generated by lonacc.pm when
>>>&Apache::lonnet::symbverify() returns 0. This can occur if there is a
>>>problem with the symb (a resource identifier which includes the url,
>>>as well as map context), or if the url of the resource is absent from
>>>the corresponding /home/httpd/perl/tmp/$uname_$udom_$cnum.db file
>>>(e.g., /home/httpd/perl/tmp/raeburn_msu_33803011027874598msul1.db)
>>>which contains information about resources in a course. This .db
>>>file is initially constructed during course initialization after a
>>>role is selected in a course.
>>>
>>>I don't see any difference between 2.7.99.0 and 2.7.99.1 as far as
>>>this behavior is concerned. My guess is that the loncontrol restart
>>>re-enabled connectivity between access server and library server such
>>>that the next time the $uname_$udom_$cnum.db file in
>>>/home/httpd/perl/tmp
>>>was updated (for a specific user for the particular course) the
>>>information form the course's homeserver about available resources was
>>>complete and symbverify() returned a true value for the symb for the
>>>/res/fsu/ng/mathReview/geometry/arcLength.problem resource.
>>>
>>>I tested this out in the MSU domain using a student role in a session
>>>running on a 2.7.1 access server for a course on a library server
>>>running 2.7.99.1, which I assume is the configuration you had (based
>>>on the versions numbers reported by the log-in pages for the various
>>>FSU LON-CAPA servers). I did not encounter the "Invalid Access"
>>>condition for an instance of your resource:
>>>/res/fsu/ng/mathReview/geometry/arcLength.problem which I had included
>>>in my course, when either first displaying the resource, or
>>>subsequently submitting an answer.
>>>
>>>I would recommend replacing 2.7.99.0 with 2.7.99.1 on a production
>>>server, as the latter does fix a few small issues in the 99.0 version
>>>(the initial testing release for 2.8).
>>>
>>>Stuart Raeburn
>>>MSU LON-CAPA group
>>>
>>>
>>>
>>>
>>>Quoting "H.K. Ng" <hkng at fsu.edu>:
>>>
>>>>The problem seems to be related to 2.7.99.1 loncontrol. When I stop
>>>>loncontrol, it says that lonhttpd is not running, but 2.7.99.0 does not
>>>>give that message and does not have lonhttpd running. Installing
>>>>2.7.99.0 solves the problem. -hk
>>>>
>>>>
>>>>At 12:52 PM 1/7/2009, you wrote:
>>>>>Hi,
>>>>>
>>>>>This morning is the start of the spring semester and when students
>>>>>tried to submit the answer the following message shows up
>>>>>
>>>>>
>>>>>
>>>>>LON-CAPA Access Control
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>----------
>>>>>
>>>>>
>>>>>Access : Browse resources
>>>>>Resource: /res/fsu/ng/mathReview/geometry/arcLength.problem
>>>>>Action : Invalid Access
>>>>>
>>>>>
>>>>>----------
>>>>>
>>>>>
>>>>>
>>>>>Sorry ...
>>>>>
>>>>>
>>>>>
>>>>>This action is currently not authorized.
>>>>>
>>>>>Initially I thought it has to do with the open date being
>>>>>incorrectly set but that doesn't solve it. Seems to work on the
>>>>>library server but not on the access servers.
>>>>>
>>>>>Any idea what may be causing this?
>>>>>
>>>>>Thanks,
>>>>>-hk
>>>
>>>
>>>_______________________________________________
>>>LON-CAPA-admin mailing list
>>>LON-CAPA-admin at mail.lon-capa.org
>>>http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
>>
>>_______________________________________________
>>LON-CAPA-admin mailing list
>>LON-CAPA-admin at mail.lon-capa.org
>>http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
>
>
>
>_______________________________________________
>LON-CAPA-admin mailing list
>LON-CAPA-admin at mail.lon-capa.org
>http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
More information about the LON-CAPA-admin
mailing list