Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions docs/Installation.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ where pref_name = 'LOGGER_VERSION';
To uninstall an older version of logger, see the [Uninstall](#uninstall) instructions. If necessary, you can download the correct version from the [releases](https://github.com/oraopensource/logger/tree/master/releases) folder.

### Install Through APEX
Logger is no longer supported from a web-only installation if the schema was provisioned by APEX. Essentially the APEX team removed the "create any context" privilege when provisioning a new workspace, likely for security reasons. I agree with their choice, it unfortunately impacts logger.
Logger is no longer supported from a web-only installation if the schema was provisioned by APEX. Essentially the APEX team removed the "create any context" privilege when provisioning a new workspace, likely for security reasons. I agree with their choice, but it unfortunately impacts logger.

<a name="install-into-new-schema"></a>
## Install into a new schema
Expand Down Expand Up @@ -90,13 +90,13 @@ To uninstall Logger simple run the following script in the schema that Logger wa

<a name="restrict-access"></a>
## Restrict Access (Grants & Synonyms)
You may want to [install Logger into it's own schema](#install-into-new-schema) for various reasons. Some of the most common ones are:
You may want to [install Logger into its own schema](#install-into-new-schema) for various reasons. Some of the most common ones are:

- DBA does not want to give `CREATE ANY CONTEXT` access to your user.
- If this is the case, the DBA can then lock the Logger schema after running the grant scripts (below) to prevent any access to the privileged user.
- Restrict Logger to never be able to access your data. *Note: Logger does not try to reference any of your data. Some security policies require that 3rd party solutions can not reside in the same schema as your data. This follows the concept that Logger doesn't need to see your data, your schema just needs access to Logger.*

Once you have installed Logger into it's own schema they're two additional scripts that need to be run. The first grants the appropriate privileges to your schema and the second will create synonyms in your schema.
Once you have installed Logger into its own schema there are two additional scripts that need to be run: the first grants the appropriate privileges to your schema and the second will create synonyms in your schema.

Run as the user with Logger installed:

Expand All @@ -122,7 +122,7 @@ Run as the user that needs to access Logger:

<a name="config-logger-levels"></a>
### Logger Levels
They're various logger levels. To see the complete list, go to the [Constants](Logger API.md#constants) section in the Logger API.
There are various logger levels. To see the complete list, go to the [Constants](Logger API.md#constants) section in the Logger API.

### Enable
To enable logging for the entire schema:
Expand Down Expand Up @@ -200,11 +200,11 @@ Logger stores its configuration settings in LOGGER_PREFS. These are the followin
</tr>
<tr>
<td>PREF_BY_CLIENT_ID_EXPIRE_HOURS</td>
<td>Default time (in hours) that client specific logging levels are set for.</td>
<td>Default time (in hours) for which client specific logging levels are set.</td>
</tr>
<tr>
<td>PROTECT_ADMIN_PROCS</td>
<td>If TRUE then only user, defined in INSTALL_SCHEMA, can run privilidged procedures.</td>
<td>If TRUE then only the user defined in INSTALL_SCHEMA can run privileged procedures.</td>
</tr>
<tr>
<td>PURGE_AFTER_DAYS</td>
Expand Down