Project

General

Profile

Actions

Bug #1232

closed

cookie needs to be written after knb page login

Added by Matthew Brooke over 20 years ago. Updated over 16 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
metacat
Target version:
Start date:
12/05/2003
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
1232

Description

this actually applies to code in the KNBWEB cvs module, but the consequences
apply to metacat.

here's the scenario:
1) a user logs in on knb homepage (knb.ecoinformatics.org/index.jsp)
2) the search form then has a hidden sessionid field added to it by the jsp
3) user then does a search and gets some private datasets in results
4) what I haven't done is to add the sessionid to the results links
- so when user clicks a dataset, metacat assumes user is "public"
5) when you get "into" a dataset, there are even more links that would need the
sessionid added

...so, the easiest solution would probably be just to write a cookie on login.
This code would probably go in <knbweb_cvs>/includes/include_session_vars.jsp,
where there is a code block for handling login (add code to create cookie here),
and another for handling logout (destroy cookie).

Sample code for writing cookies from java currently exists in the Metacat
module, in the HttpMessage class


Related issues

Blocked by Metacat - Bug #1819: Access control - deny public/allow user read: user couldn't readResolvedSaurabh Garg12/08/2004

Actions
Actions #1

Updated by Matthew Brooke about 20 years ago

What I've done:

(4) has been temporarily resolved by adding:

form_ref.sessionid.value="&lt;current sessionID here, or "" if not logged in&gt;";

to the JS function: submitform(action,form_ref) in resultset.xsd, so that all
the links on the results page include a hidden sessionID field in the POST data.

STILL TO DO:

(5) is NOT solved by the above temp fix, because EML stylesheets do not
propagate this sessionID value.

FULL FIX should consist of doing what is detailed above ("write a cookie on login.
This code would probably go in <knbweb_cvs>/includes/include_session_vars.jsp,
where there is a code block for handling login (add code to create cookie here),
and another for handling logout (destroy cookie).

Sample code for writing cookies from java currently exists in the Metacat
module, in the HttpMessage class")

When this is done, probably best to remove the temp fix described above
(sessionid in submitform()), and maybe even to remove sessionid hidden fields in
search form JSP?? Need to consider carefully.

Note also that writing the cookie client-side, using javascript may be an easier
option? Need to evaluate both methods and pick best.

Actions #2

Updated by Saurabh Garg almost 20 years ago

Fixed the bug by adding code in default skin and knbweb seperately. knbweb
needed seperate code because two domain names are involved -
knb.ecoinformatics.org and metacat.nceas.ucsb.edu. Hence cookie was needed to
be set accordingly. Done majorly with Matthew Brooke's help.
The changes are on knb.ecoinformatics.org and can be checked in behaviour by
anyone. I have tested changes in both default and knb skin. In short people
dont need to go to dev/loginonly.html now.

sessionid from various urls can be removed if this works ok.

Actions #3

Updated by Saurabh Garg about 19 years ago

Changing the target milestone to release 1.6. Cant be included in 1.5 which has
to released soon.

Actions #4

Updated by Saurabh Garg over 17 years ago

Merging bug 1819 into this bug as it refers to the same problems.

I created three DPs for which I had set the Access Permissions so the public
would be denied access and I (uid=connolly,o=NCEAS,dc=ecoinformatics,dc=org)
would be allowed to read. When I tried accessing the data from the KNB web site
(after I logged in as uid=connolly,o=NCEAS,dc=ecoinformatics,dc=org), I got a
message saying "User public does not have permission to read the document".

Actions #5

Updated by Saurabh Garg over 17 years ago

  • Bug 1819 has been marked as a duplicate of this bug. ***
Actions #6

Updated by Saurabh Garg over 17 years ago

The session information is not maintained by the skin for some reason. So the JSP part knows that is in session but the non-JSP part doesnt. Most probably the cookie specifying the JSESSIONID is not set in the browser and that is what needs to be fixed.

Actions #7

Updated by Chris Barteau almost 17 years ago

I believe that I found the cause, in regards to the last comment. Some of the page (i.e. the login iframe) uses an instance of MetacatClient, which is basically a JSP helper class. It has the client-side login API, and keeps track of the sessionId (available anytime via getSessionId()). The code in this class then creates yet another session for communicating with MetacatServlet. The rest of the skin communicates directly with MetacatServlet; thus, there are actually 3 sessions involved, two of them apply to the web page and one between MetacatClient and MetacatServlet. The solution is to re-write the offending web page to have all client communication thru MetacatClient (will need to add methods as needed). Unless there is a reason to create a new session between MetacatClient and MetacatServlet, then that code code be removed and just call the Servlet as a POJO passing on the request and response that MetacatClient already has.

Actions #8

Updated by Chris Barteau almost 17 years ago

On re-thinking my solution, the main idea is to have the entire page using the same session, so taking the iframe out, and putting the login in the main page would accomplish this. It would also give the entire page access to the MetacatClient instance.

Actions #9

Updated by Chris Barteau over 16 years ago

Login form should be placed in the center iframe, since that is the "main" session.

Actions #10

Updated by Jing Tao over 16 years ago

move to 1.7.1

Actions #11

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 1232

Actions

Also available in: Atom PDF