Middleware
Beehive
This page discusses ways to make Oracle Beehive Web services API available within and outside your enterprise while ensuring secure access to your Oracle Beehive deployment.
Authenticated access to Oracle Beehive Web services APIs should, by default, be available to all users in your enterprise. However, the configuration of your Oracle Beehive deployment varies depending on how users access Oracle Beehive Web services API.
A primary concern for the application developer is how to account for modern browsers' protection against Cross Site Scripting (XSS). These browser prevent an application (for example) served by the host
a.us.oracle.com to make HTTP calls to another domain, such as
beehive.oracle.com.
This section describes several solutions to enable browser-based clients to handle data across multiple domains while maintaining the integrity of your Oracle Beehive deployment.
Suppose you have deployed Oracle Beehive on
beehive.oracle.com and your Oracle Beehive Web services application is hosted on
a.us.oracle.com. A user accesses your Web application with the URL
www.oracle.com/someapp, which you have configured to be redirected to
a.us.oracle.com. Your Web application calls the Oracle Beehive RESTful Web services resource
www.oracle.com/comb/v1/a_resource, which is redirected to
beehive.oracle.com.
From the client's point-of-view, all calls appear to be directed to www.oracle.com, and thus the browser allows these calls to be performed.
Note that this configuration is not supported for production environments.
In this configuration, Oracle Beehive's Apache HTTP server is used to send HTTP requests as proxy requests.
Add the following lines to
<Oracle Beehive home>
/Apache/Apache/conf/httpd.conf (or anywhere outside a block):
ProxyPass /someapp http://a.us.oracle.com ProxyPassReverse /someapp http://a.us.oracle.com
/someapp is the location of your Web application, and
a.us.oracle.com is where you are hosting your Web application.
Since you do not require Oracle Beehive to be used as a forward proxy, you do not need to restrict access to it. However, you may by adding the following section in
httpd.conf:
<Directory proxy:*> Order Deny,Allow Deny from all Allow from us.oracle.com </Directory>
Restart the Apache HTTP Server with the following command:
<Oracle Beehive home>/opmn/bin/opmnctl restartproc process-type=HTTP_Server
You may build an application and deploy it to WebDAV. A user may then log into WebDAV and run your application within WebDAV. Consequently, your application will have access to Oracle Beehive without the browser having to look in different locations.
Note that this configuration is not supported for production environments.
You may simply put your Web application in
<Oracle Beehive home>
/Apache/Apache/htdocs.
Figure 2-4 Using Oracle Beehive Apache HTTP Server
Rich Internet applications run a virtual machine within the browser. They have similar XSS JavaScript safeguards. However, they provide another way to enable your application to handle data across multiple domains.
This accomplished with a
crossdomain.xml file placed in the root directory of the HTTP Server to which the client application would like to connect. You may use a master policy site to dictate the policy for whole site. The master policy specifies which local files are allowed to change permissions.
Refer to one of the following pages depending on which technology you are using to develop your application: