I exported an application from one oracle apex 19.2 host and sucessfuly imported it to another oracle apex 19.2 host. But when I start the application, I get the following error:
You are not authorized to view this application, either because you have not been granted access, or your account has been locked. Please contact the application administrator.
Access denied by Application security check
Technical Info (only visible for developers)
is_internal_error: true
apex_error_code: APEX.AUTHORIZATION.ACCESS_DENIED
component.type: APEX_APPLICATION_AUTHORIZATION
component.id: 14644239902526063
component.name: Reader Rights
So what could be the problem?
Thanks.
Validate Security Attributes in your application. If you're using Access Control User Role Assignments for Source for Role or Group Schemes, you need to add the roles and propers users in Shared Components -> Application Access Control.
Related
We have a windows application which allow users to connect to SQL using windows authentication.
The problem is the users of that application also have SSMS installed on their desktops so they can also connect to prod db using windows authentication.
Is there any way wherein we can restrict users from accessing prod db using windows authentication on SSMS but they should be able to access windows application from their local system using windows authentication?
If I understand your scenario correctly:
You have an internal local database on Server 'A'
You also have a production database on Server 'A'
Using your custom windows application, users can only see the local non-production databases
However, using SSMS users can see both production and local databases on Server 'A', and you would like only authorized users to be able to see production databases.
If this is the case, what you want to do in SSMS is revoke database view rights to all production databases unless the user is a sysadmin or owner of the database. Run the following on your server:
USE MASTER
GO
DENY VIEW ANY DATABASE TO PUBLIC
GO
After you run the above statement, you will not be able to see any databases in SSMS unless you are a sysadmin or your login is the owner of a database.
Source:https://www.mssqltips.com/sqlservertip/2995/how-to-hide-sql-server-user-databases-in-sql-server-management-studio/
Maybe you could restrict access to your database objects by using application roles ... Msdn: "You can use application roles to enable access to specific data to only those users who connect through a particular application."
OBIEE 11g Users are not visible in Identity Manager within Administration Tool which are created in Weblogic.
Login The Oracle WebLogic Server Administration Console. In the Security Realms Create user and assign them Groups BIAuthors, BIAdministrator and BIConsumers .
Open BI Administration Application. Open an offline repository. Go to Manage->Identity. All users which are created should be displayed over there but only weblogic user is displayed there.
Any thoughts?
Open the BI Administration Tool and open the repository in online mode.
Open the Identity Manager from Manage menu and check the list of the existing
users. You'll only see the weblogic user account.
Click on the Set Online User Filter... option from the Action menu.
Enter * as a wild character to import all user identities.
You'll see all the user accounts.
I need to restrict access to Oracle Database via tools like Toad, SQL Developer etc.
Only the request coming from Application Server should be allowed to connect successfully.
You can:
Restrict access to DB on Firewall level
Restrict access to DB via Listener configuration (listener.ora)
Restrict access to DB via logon trigger on schema. You can find templates of such a trigger on the Internet. Basically you have to select from sys_context function(or from v$session view). This will tell you all the information you need. Then any exception raised from logon trigger aborts the connection.
Grant access to users, but do not give them any privs. Then grant necessary privs to password protected role and enable this role via "SET ROLE" ONLY from the application.
Or you can mix these approaches as you want.
I have shared computer, where admin install Oracle XE. But I cannot e.g. create new user, because I have not rights in OS, afaik.
In Oracle documentation written that DBA should be member of administrator group.
Does exists way that I can manage local instance XE without admin rights?
I need start/stop database, connect/disconnect, kill session etc. It is need for test my Java application.
Thanks.
You don't need an OS user with admin right (once Oracle is installed and running).
Just connect as SYSDBA then you can create new Oracle users and manage the complete database..
(I do that on XP as well - working with regular user, but connecting as SYSTEM or SYS with the SYSDBA role if I need to configure something in Oracle)
Does exists way that I can manage local instance XE without admin rights?
Probably not ... if that's what the Oracle documentation says.
A sensible strategy would be to discuss your problem with the admins. Point out that it makes it difficult for you to do your job if you don't have access rights. If they won't grant you system Admin rights, ask them to suggest alternatives that will allow you to do your job.
It may be simply that they need to grant you additional rights in Oracle.
How about getting admin rights in a Virtual Machine? See virtualbox.org.
From XE manual here :
" On each platform, if the OS authentication user group does not already exist, it is automatically created when you install Oracle Database XE. In addition, upon installation on the Linux platform, the user account oracle is automatically created and placed in the dba group. Upon installation on the Windows platform, the user performing the installation is automatically added to the ORA_DBA group. On both platforms, you can add other host users to the OS authentication user group to enable them to connect to the database with the SYSDBA privilege. "
Since installation on windows needs admin user which I assume you are not, so it renders the automatic addition of that admin user to ORA_DBA group useless for you.
So what your admin can do immediately after XE installation on this shared machine is just add your non-admin OS user (local or domain level, whatever) to the newly created OS local group "ORA_DBA". Once this is done, you can simply open the sqlplus prompt and connect with SYSDBA privilege using your own non-admin user in future:
connect / as sysdba
However, you will still not be able to restart the Oracle service or the TNS listener, even if you are in the ORA_DBA group.
I am unable to grant my primary work domain account the privileges to create database objects in DB2. Here is my current setup:
OS is Windows 7 enterprise 64-bit
DB2 version 9.7 Enterprise edition
DB2 extended security was enabled during installation
My domain account is member of the Administrators group as well as the DB2ADMNS and DB2USERS groups.
The DB2ADMNS group is granted all authority privileges.
DB2_GROUP_LOOKUP is set in the environment to LOCAL
DB2 sysadm_group is set to DB2ADMNS
The DB2 instance has been restarted but my domain user still cannot create database objects like bufferpools. I created a local administrator account and added it to the DB2ADMNS and it was able to create the bufferpool objects.
I tried using the db2admin user to give all authorization privileges to my domain account in the DB2 control center but my domain account is not showing up in the drop down containing the users.
I removed the DB2_GROUP_LOOKUP environment variables and restarted the DB2 instance then tried to give my domain account user enough authorization privileges and now my domain account in showing up in the drop down. Once the changes are applied, I restarted the database instance and tried the bufferpool creation and it still fails.
Am I missing a configuration step in giving my user enough privileges? I need to have this configured as the IBM product I am installing fails if this privilege is not working. Thanks.
In 9.7 DB2ADMNS is not supposed to be able to access any data. SYSADM level accounts are reserved for maintenance tasks and should not be used for data access. Remove your connecting user from any special groups, and grant after that the proper access rights.