June 27, 2006, 09:01 AM
mgrackinI have been looking at using the WebFOCUS logon page to get the logon information. However, I am also experimenting on how to lock down access to a particular application so that a person cannot get around the logon security by accessing the HTML files directly or issuing a call to WebFOCUS to execute a FOCEXEC directly.
Right now I am adding script commands into the SITE.WFS to control all requests to WebFOCUS to make sure they include specific pieces of required information. I am also dynamically adding the directory for the application to the APP PATH with a profile FOCEXEC via the _site_profile setting. Keeping the directory off the APP PATH until needed prevents people from running the FOCEXECs directly. I am trying to code the SITE.WFS file so that people are forced to logon before the application directory is added to the APP PATH.
I hope this makes sense. I haven't quite got it all worked out yet. Hopefully I will find a solution which I can then post here for others to use if needed in the future.
I mainly am coming up with an idea and then I am thinking about how I would break it. Then I go back and try to close that hole while at the same time trying to not affect applications that do not have access restrictions.
June 27, 2006, 09:02 AM
mgrackinJust another note, I do not need to use DBA because all authorized users can see all data. Therefore I only need to concern myself with access to the application.
June 27, 2006, 11:51 AM
mgrackinI almost have this working. The only problem is that the IBIC_user variable seems to be NULL or blank after a successful logon. I am doing an <IF> test on IBIC_user in the SITE.WFS file to make sure a value exists but it is not populated with the user id for all subsequent report requests after the initial successful logon.
Has anyone had this problem with WF7.1.3 and found a way around it.
June 28, 2006, 10:26 AM
TexasStingrayHave not had this problem. But, let me describe what we are doing at one location. Using the DOT NET NUKE portal the users are forced to login. Then a domain level cookie is being created because the portal is on a different virtual web server then the WebFOCUS client. Having a domain level cookie allows the to sites to share the cookie. The cookie is then passed to the Reporting Server using CopyCookieVarToWFVar in the site.wfs. Then in each focexec we include a securty check focexec and pass in variables like the cookie, facilityid and reportid. The security focexec issues a SQL request passing these values as where statements, if a record is returned then the user has access to; 1) run the report, 2) access the data for the requested facility. If no records are returned then access is denied and an html page is displayed telling the user they do not have access to the requested information. You said you don't need DBA level security, WebFOCUS DBA level security can be used to control access to the data without controling field and/or value level. just by using
USER=TOM,ACCESS=R,$
.....
USER=SAM,ACCESS=R,$
then if the user is not listed in the DBA section they cannot access the data.
Hope this Helps