Thursday, April 10, 2014

Oracle Application Express (APEX) 4.2.5 is now available for download

A new minor release of Oracle Application Express (APEX) has been announced yesterday.
Version is now available for download.

Check out the accompanying documentation for new features and bugs fixed in this release.

You may also find interesting reading Joel's blog posting about Apex 4.2.5.

Thursday, April 03, 2014

On HTTP 401 Unauthorized (with Oracle EPG)

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

It could happen that suddenly your Apex application that has been working for years starts asking for a username and password in order to access the XDB repository.
You hit the Cancel button and all you get is:
401 Unauthorized

No html, no images, nothing is returned, your app is blank.
What the hell happened with it?

How could this happen if I didn't change anything in a long time?
Where do I start looking first?

First of all, we need to assess what's gone awry.
If you are a Firefox user, Firebug comes in handy with its panels: check out the "Net" panel and see which component is giving troubles.

In a previous posting, I had problems with static files and images in the repository, but not with the main Apex component, the f function that is processing and returning the main HTML page.

If the page is just "garbled" and some components are missing, the problems are likely caused by permissions set at the XDB resource level (see the previous posting about this).

If HTTP 401 is returned by the main page itself instead, either there is problem with the XDB configuration file or what else?

In the former case, you should compare the current xdbconfig.xml with a working backup copy (some time ago I wrote a posting also about recovering a corrupted xdbconfig.xml, check it out).
It's absolutely necessary to keep backup copies of working configurations that will save your time in case of troubles like these, allowing you to make comparisons or quickly restore them if anything went wrong and it's much better than guessing its content without knowing if a certain option was set or unset when the system was running just fine.

Now, supposing the xdbconfig.xml is ok, still the same as before, where else should I turn my attention to?
Luckily enough, my sixth sense told me to look next at the database user status.
OK, great, but which one?

Depending on your configuration you may have a couple of Apex database users that have been created over time:
The good one is returned by the following query if the database is XE with EPG (Embedded PL/SQL Gateway) and the DAD is named APEX:

-- DBA user required
select dbms_epg.get_dad_attribute('APEX','database-username') d from dual;

The next step is to check what's the status of user ANONYMOUS.

select account_status, lock_date, expiry_date
  from dba_users
where username = 'ANONYMOUS';

ACCOUNT_STATUS                   LOCK_DATE           EXPIRY_DATE       
-------------------------------- ------------------- -------------------
LOCKED                           01-04-2014 18:37:26                    

Here is the answer. A locked account will make your Apex site look miserable in no time.
Just unlock the account ALTER USER ANONYMOUS ACCOUNT UNLOCK and everything will resume working immediately.
Thereafter you just need to find what or who made that account become locked suddenly, but that's another story.

Thursday, January 16, 2014

Random XDB authentication problems with Apex and EPG: problem solved? So it seems.

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

This is the sort of things I hate, because I cannot fully explain why it works the way it does, anyway, here is a short account of what happened:
Some time ago I installed Oracle XE 11g on an Oracle Linux VM.
Upgraded Apex to 4.2.3
Installed all my applications with little effort if we exclude some glitches when importing nested tables using Oracle data pump.
Then, using WebDAV, I attached the XDB folder to my Mac running on Mavericks, authenticating as user SYSTEM.
I created my own folders in XDB and migrated all the stuff from my previous environment using the O/S copy and paste feature.
When I opened the applications referring to items stored in these folders I was randomly getting the infamous XDB authentication pop up window.
It's worth noting that I had already added the following privilege to xdbconfig.xml in the root folder of XDB.

<allow-repository-anonymous-access xmlns="http://xmlns.oracle.com/xdb/xdbconfig.xsd">true</allow-repository-anonymous-access>

In order to understand what's wrong, I enabled Firebug's Net console in Firefox and I found out that some of these items, but not all of them, where not downloaded owing to some HTTP 401 (Unauthorized) exception.
The best part, that one I really love, was that if I reloaded the page after hitting the Cancel button, the unathorized exception was returned by different items, not the same ones or a mix of them (some were still unathorized, while others didn't).
As I repeated the reload requests, Firefox caching mechanism was gradually filling the gaps, i.e. not requesting the same stuff again once cached, so I ended up with all the items and no more authentication requests.
If I purged the cache, the predicament was commencing all over again.

At this point I decided to compare the ACLs of Apex's built-in /images folder and mine and it turned out that the only difference was the absence of the privilege highlighted in blue:


So I updated the ACL of the folder and no more XDB authentication requests ever since.

What I can't figure out is why I should get the HTTP 401 *randomly* and not systematically because of the lack of this privilege.

If someone could explain the mistery...

yes you can!

Two great ways to help us out with a minimal effort. Click on the Google Plus +1 button above or...
We appreciate your support!

latest articles