We are going the OID way because of these problems.
Anyway here is a wild idea:
Tell the web guys to use the user userid (he probably logged to the web
application) with a standard password that is common to all of them and is
supplied by the web application, the user does not see it.
If you
Hi Jared,
The users don't have to authenticate in the application because they've been
setup in active directory.
It may be similar to SAP, except we don't have the SAP developers in-house
making production changes without telling anyone. That's why I wan't to lock
it down. In the past the
I like the idea of roles and that's what I'm trying to get at, but the app
determines the user's authority prior to connecting to the database by
looking at a key in active directory. The database connections have to
connect as the highest level user possible, which is the application admin.
I
I'm going to start looking at OID.
thanks,
steve
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Sunday, November 30, 2003 4:49 AM
We are going the OID way because of these problems.
Anyway here is a wild idea:
Tell the web guys to use the
I like the idea of setting the client info.
The consensus on the other stuff is that's just the way it is.
thanks,
steve
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Saturday, November 29, 2003 11:34 PM
On 2003.11.29 22:49, Steve Perry wrote:
Multi-Org in Oracle Applications works (well) with this client info setting
and views having where clauses on client info.
Tanel.
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Monday, December 01, 2003 6:19 AM
I like the idea of setting the
What is Multi-Org? Sounds like a brand of kitchen utensils?
On 2003.12.01 00:39, Tanel Poder wrote:
Multi-Org in Oracle Applications works (well) with this client info setting
and views having where clauses on client info.
Tanel.
- Original Message -
To: Multiple recipients of
Technically it's a means for doing row-level security in Oracle Apps (in
functional side there's of course more).
It's just a bunch of views on base tables. All base tables have org_id
column in them and the views include a clause where they compare rows org_id
to organization id taken from
Steve,
I'm not a web developer either, but I do know that this
is a very common method of handling the database connections.
Many 2 tier apps work this way as well. SAP for example.
Unless you have influence on the architecture and can
present a convincing argument, you best learn how to
work
On 2003.11.29 22:49, Steve Perry wrote:
I hope somebody on the list can help me out with this.
All of our 3-tier apps are architected with a schema owner (owns all objects
used by an application) and application user (no create privs, but it does
have full dml privs to the schema owner
Well ... in general it's the apps that manage the system security, and
the DB users are there to prevent the app users from doing damage, but
in general these two work in unison.
I have not seen any decent ways of having the DB administer users
without there being a serious overhead, in terms of
11 matches
Mail list logo
