|
In this section: |
|
How to: |
The DBA password defines access to data sources on the Server. Each data source description can specify which passwords are acceptable for accessing the data source. Each password may also be associated with specific access types, conditions, and rules that limit access down to the row level, if necessary.
The SET PERMPASS=password command establishes a password that the user cannot change for access to data sources. You can assign a value to this command this in the SERVER as SET PERMPASS=&FOCSECUSER. You can control whether a PERMPASS command is sent to the Server with each request with the DBA Source (IBIF_DBAPASS_SRC) setting.
Database security is described in the Describing Data With TIBCO WebFOCUS Language manual.
By setting the DBA password for each request, you establish a single sign on from Managed Reporting to the data source on the Server.
TIBCO ReportCaster also supports the DBA password, which is sent in encrypted form to TIBCO ReportCaster. The DBA password cannot be assigned a TIBCO ReportCaster group ID because a single password can be associated with multiple groups. It can be set to the domain ID, the user HREF, or to a user-specified variable.
When you receive a message that the change was saved successfully, click OK,
To access the user ID in a report request, use the protected Server variable &FOCSECUSER. This variable contains the connecting user ID, except when Server security is OFF. &FOCSECUSER is recommended over previous approaches, such as the GETUSER and CNCTUSR subroutines.
To set a DBA password from the connected user ID that cannot be changed in a procedure or configuration file, you can place the following sample code anywhere in the Server profile (edasprof.prf):
SET PERMPASS = &FOCSECUSER
For more information about DBA security, see the Describing Data With TIBCO WebFOCUS Language manual.
Deferred Receipt is a Managed Reporting feature that allows users to submit a Managed Reporting procedure that executes in the background. The user then views the finished report output from the Deferred Report Status interface in Managed Reporting. This is in contrast to procedures submitted for immediate execution, where the browser waits for the request to finish.
From a security perspective, deferred requests are accepted by the Server in the same way as immediate requests. If Server security is enabled, the deferred request must connect with a valid Server user ID and password.
When a request completes, its output is stored in a file on the Server, in the drive:\ibi\srvnn\wfs directory, where nn is the number of the current release. The output is accompanied by a corresponding file that contains the user ID that submitted the request and other information. The Server ensures that only the user who submitted the deferred job can retrieve, delete, and check the status of the output file. The Server Administrator (the user identified by the server_admin_id keyword in the edaserve.cfg file) can also view and delete any deferred output, but can do so only at the file level or by using the Server Console.
Note: When you delete a deferred request, a confirmation message appears, by default. A deletion requires two clicks. You can choose to suppress the confirmation message, meaning a deletion requires only one click. This is done using the setting described in Deferred Reporting Settings. Making a large number of deletions is faster when you suppress the confirmation message.
Access to the dfm_dir directory should be restricted so that the user ID that started the Server has read/write access. Read access should be controlled so that unauthorized users cannot gain access to the directory.
A deferred ticket is stored in the Managed Reporting Repository for each deferred request. The tickets are stored by each Managed Reporting user. Users can only see their own deferred tickets, except for an administrator who has access to Manager Mode. The ticket contains the node of the Server on which the output resides.
When a user requests Deferred Status, all of the tickets belonging to the user are processed at once. If credentials are required to retrieve status from one of the servers, the dynamic server sign-in form appears. If one or more of the servers is temporarily unavailable, the status of those tickets display as unknown.
If a user has submitted a deferred request one day with the user ID user1, and then submits the same request the next day with the ID user2 and checks deferred status, the user will be unable to access the request from the previous day and will see an error message.
To access the first report, the user needs to close the session and sign in to the Server as user1.