| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1100.1 | OAINI.SCP? A good place to set OA$FILE_SEARCH_ORDER | VITARA::REDMOND | Thoughts of an Idle Mind | Wed Jul 22 1992 16:22 | 8 |
| GET OA$FILE_SEARCH_ORDER = list of directories? Do this in an
OAINI.SCP.
Maybe something like:
.FX .IF OA$PROFIL_PRVAPP EQS "" THEN GET OA$FILE_SEARCH_ORDER = ...
Tony
|
| 1100.3 | A Warning | CESARE::EIJS | All in 1 Piece | Thu Jul 23 1992 09:17 | 12 |
|
Hi Ricardo,
.1 Is the solution. However, if you talk about 'non-privileged user'
does this mean that they have 'PRVXOWN' also set to 'N'? If this the
case, .1 will not work as OA$FILE_SEARCH_ORDER suddenly becomes a
Read-only symbol. I've mentioned this before in one of the former
notes, but I'm still looking for an easy workaround.
Ciao,
Simon
|
| 1100.5 | | KAOFS::R_OBAS | | Mon Jul 27 1992 22:29 | 7 |
|
Hello,
The PRVXOWN is set to "N". He's hoping for workaround without allowing
any priviledges to users. I guess he'll just have to wait.
regards,
ricardo
|
| 1100.6 | Suggestions for applications | CESARE::EIJS | All in 1 Piece | Tue Oct 13 1992 13:44 | 53 |
|
Hi,
Several notes have already explained what the PRVXOWN field will do so
a little wrapup:
The field PRVXOWN is introduced to prevent users from calling own forms
(e.g. USER.FLB) and procedures from directories which are not referred
to by an Executive logical. One of these logicals is OAUSER, but also
OA$TEMP.
Another feature of PRVXOWN is that, if set to 'N', the symbol
OA$FILE_SEARCH_ORDER will change from Read/Write to Read-only. This
means that a procedure like OAINI.SCP, which is frequently used to
modify this symbol (amongst many other tasks), cannot be used to do
this once this field is set to 'N'.
All changes (including the changes for PRVUDPFNC and PRVUDPCMD) are
made to comply with the new security enhancements.
To facilitate this the following changes have been made:
- All Scripts, Boilerplates are included in the TXL
- The Script and Boilerplate directories are closed for the world
- OA.BLI changed to make OA$FILE_SEARCH_ORDER Read-only
- The symbol OA$FORM_SEARCH_ORDER is still Read/Write but will
ignore form libraries which reside in directories not referred to
by a Executive logical
We suggest to apply the following 'rules' to applications:
- All Scripts (DO and SCRIPT) and Boilerplates should be put in the
TXL
- Make sure form libraries reside in directories referred to by
Executive logicals
- All other procedures called from Forms and Scripts/Commands
should include a directory reference (Executive), preferable a
search list (like OA$LIB:) so that Site elements are called
before Base elements
- Avoid any change to the OA$FILE_SEARCH_ORDER from OAINI.SCP
If the suggestions given cannot be applied than it should be documented
that the PRVXOWN field should be set to 'Y' to prevent the application
from not functioning properly.
Hope this gives an answer.
Ciao,
Simon
PS A bit late, but...
|
| 1100.7 | | KAOFS::R_OBAS | bLuE jAYs kNoWS ALL-IN-1 | Tue Oct 13 1992 17:30 | 8 |
|
Hello,
I gave the suggestion in .6 to the customer. It still does not
solve their problem (according to the customer) because they do not
want to set the PRVXOWN to "Y".
He's happy though that he is getting a feedback on this problem.
ricardo
|
| 1100.8 | Let's back up and ask why | A1VAX::BARTH | Shun the frumious Bandersnatch | Wed Oct 14 1992 16:09 | 19 |
| It sounds like the answer is "allow your users the privilege to change
OA$FILE_SEARCH_ORDER - that privilege is PRVXOWN."
And the customer is saying, "Give me a way to change
OA$FILE_SEARCH_ORDER without the privilege to do it."
:^)
Perhaps you could explain it to the customer that PRVXOWN is required
for changing of the OA$FILE_SEARCH_ORDER.
An alternative solution, though, may be to look at WHY the customer
thinks he needs to change the search order. If the application is
"live" and everything is in the TXL and FLCs, etc, then is it really
necessary to munge the search order?
OK, it isn't an answer. But perhaps it may help to get to one.
~K.
|