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:
<ace>
<grant>true</grant>
<principal>ANONYMOUS</principal>
<privilege>
<read-properties/>
<resolve/>
<read-contents/>
</privilege>
</ace>
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...
3 comments:
I'm far from being a pro, but I get the error, when I add some custom css on a page that references a background picture. (In this case, I'm trying to change the background pic in the applications title bar (Apex 4.2.3, Theme 26))
As usual more complicated than I thought...
Flavio, the only thing I can think about, regarding the "bulk operations" you did, is, that the xdbconfig.xml settings where set default (and/or only one "shared_server" process??) and maybe too small regarding its setting.
Have a look here
http://docs.oracle.com/cd/E16655_01/appdev.121/e17603/xdb18res.htm#ADXDB5435
The basics regarding xdbconfig.xml can be found here:
http://docs.oracle.com/cd/E16655_01/appdev.121/e17603/appaman.htm#ADXDB5709
Hi Marco,
thanks for your comment.
As a matter of fact I have been using no fewer than 3 shared servers since a long time in order to work around the annoying bug of the process suddenly spinning the CPU to 100%, so I am fairly confident that the number of current shared servers was not the key problem here.
It still belongs to a short list of mysteries together with the aforementioned bug ;-)
Post a Comment