403 forbidden error in oracle apex 20.2.1 does not support Cross Origin Sharing request

Can not access to oracle apex. faced below issue when tried to login from ORDS on development mode. 

 

403 Forbidden

The request cannot be processed because this resource does not support Cross Origin Sharing requests, or the request Origin is not authorized to access this resource. If ords is being reverse proxied, ensure the front end server is propagating the host name, for mod_proxy ensure ProxyPreserveHost oi set ON.

 

Solution: 

Application ORDS is configured to access only with https://, so we have added below parameter in ORDS defaults.xml (ords/conf/ords/defaults.xml)  configuration file and restarting ORDS. it resolved the issue.  

 

<entry key="security.forceHTTPS">true</entry>

 

Application configured with ORDS in Weblogic server. 

 

 

Just FYI- 

From ORDS 20.4 onwards we can use this below parameter for cross origin sharing request

 

 

<entry key="security.externalSessionTrustedOrigins">http://example.com,https://example.com:8443</entry>

 

For more info- 

Cross-Origin Resource Sharing Feature

 

https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/22.1/orddg/migrating-mod_plsql-ords.html#GUID-ACAAB207-8475-403E-A757-304D7E76B2EF

403 Forbidden Access to the procedure named: apex is denied or wwv_flow.accept is denied

403 Forbidden Access to the procedure named: apex is denied. 

Access to the procedure named: wwv_flow.accept is denied. 

Failed to load resource the server responded wwv_flow.accept

Failed to load resource: the server responded with a status of 403 (Forbidden) 

 

Background:

Oracle APEX version 20.2 (probably same for 19.2 onwards) and ORDS 17.4 and later

Apex (version 20.2) application was running fine from last 1.5 years without any issues. Before 2 days of the incident, deployed a new apex application on the same APEX instance, it is running on ORDS (18.1) which is deployed in Weblogic application server.  

Suddenly, faced above issues when tried to login in URL:port/ORDS,  user also faced Error: Forbidden. When tried to login. so totally struck everything. No one know what happened! Nothing changed!

 

Found the Cause:

After a marathon research, we found that there was a security feature in APEX (on ORDS) kicked off - "security.requestValidationFunction">wwv_flow_epg_include_modules.authorize (This is reside in file defaults.xml  on ORDS/conf location in apps server ).  Learned that, this property and DB function work as whitelisting entries. Means it activates the whitelist of callable procedures which ships with Oracle Application Express and prohibits calls to other procedures.

As per Oracle, when a database pool is configured to use the APEX_PUBLIC_USER, ORDS automatically sets or checks the value of the property security.requestValidationFunction on xml config file (ords/conf/ords/defaults.xml)    as below.

<entry key="security.requestValidationFunction">wwv_flow_epg_include_modules.authorize</entry>

<entry key="security.validationFunctionType">plsql</entry>

 

We found that database package wwv_flow_epg_include_modules  (in schema apex_200200) and function authorize is empty. So when validating this property nothing got passed to ORDS from APEX instance.  

 

Solution:  

For temporary solution,

       1) we made this property empty with this below command.

u01/ords$ java -jar ords.war set-property security.requestValidationFunction ""

2)        2) and then bounce or stop/start the ORDS service deployment in Weblogic server by login in Admin console.

OR

You may remove these two lines from this above default.xml files 

<entry key="security.requestValidationFunction">wwv_flow_epg_include_modules.authorize</entry>

<entry key="security.validationFunctionType">plsql</entry>

 Then bounce the ORDS.

 

For details:  An Oracle REST Data Services deployment configuration contains several security related parameters. In a configuration for Oracle Application Express, Oracle recommends to set the parameter security.requestValidationFunction to wwv_flow_epg_include_modules.authorize. This activates the white list of callable procedures which ships with Oracle Application Express and prohibits calls to other procedures. This can be extended using the validation functions shipped with Oracle Application Express. https://docs.oracle.com/en/database/oracle/application-express/19.2/htmdb/web-listener-security.html

 

 https://joelkallman.blogspot.com/2016/07/securing-application-express-when-using_24.html

https://www.promatis.at/en/2022/07/13/lessons-learned-while-upgrading-apex-and-ords-to-22-1/

https://oracle-base.com/articles/misc/oracle-rest-data-services-ords-database-authentication

https://forums.oracle.com/ords/apexds/post/403-forbidden-access-to-the-procedure-named-wwv-flow-accept-5111

 

 

ORA-01017: invalid username/password; logon denied in oracle 12c Dataguard DG broker Suddenly

 It's been long time everything was working fine with oracle DG broker (dgmgrl> ).  Suddenly we faced this error in DG broker while trying to valid network configuration before a SWITCHOVER operation, even though no one change any credentials. 

After sometime, we realized that we were connected to DG broker as SYSDG user (normally connect with SYS). and then found that, the SYSDG user's credential are not same in both PRIMARY and STANDBY password file. that's why it is not able to connect. Here is the query to check this in both environments -   

SQL> select * from v$pwfile_users;

Then logout and connect back with SYS user, everything worked perfectly.

 dgmgrl> connect sys 

So solution is- 1) Either you need to change SYSDG user's credentials in both database same (since remote_login_passwordfile is set to EXCLUSIVE) . so it will saved and match in Password file.

2) OR login with a different super user (like SYS) who's credentials are same for both databases. 

For details you may read- ora-01017

 

 

Test Endpoint failed: Application-Status: 1020912, Application-Message: Network error has occurred” - Amazon Redshift as the target endpoint for AWS DMS

Of course this is a network issue but couldn’t figurable easily. I had to spent quite a good amount of time to find the issue while setting up the Redshift as a Target endpoint in AWS DMS.  

As per below docs, in #6 they mentioned- “6. Enter your Amazon Redshift endpoint for the Server name”  - https://aws.amazon.com/premiumsupport/knowledge-center/dms-redshift-target-endpoint/

Actually it won’t work (and you will get above error message) if you just copy and paste the whole Redshift cluster endpoint from Redshift Cluster general information page.  Normally Redshift cluster endpoint consist of cluster identifier + Region Identifier for cluster + database name + port.

So, the solution is for this error, you need to remove the database name and port number from the actual Redshift cluster endpoint and use this(rest of parts) in the “Server name:” field on AWS DMS endpoint creation page.

 

Hope this will save your valuable time and efforts! 

 

Alter a trigger by a procedure ORA-01031: insufficient privileges

Tried to disable and enable a trigger (which is own by another user)  by a procedure but we are getting error  "ORA-01031: insufficient privileges" event though calling user(current user) have all the neccesary proviliges like "alter any trigger"

Solution:

I hav added  "AUTHID CURRENT_USER" clause in the procedure then it started working as below - 

Just as example-

CREATE OR REPLACE PROCEDURE test
   AUTHID CURRENT_USER  ----set Invoker Rights not definer rights
is

begin

EXECUTE IMMEDIATE 'alter trigger tri_name disable'; 

.......

........

EXECUTE IMMEDIATE 'alter trigger tri_name enable'; 

 end ; 

  For Details