How can I access secure data with getting a password dialog?

This is due to a bug in certain versions of the Java Plug-in that don't properly communicate with the browser about authentication issues. Several possible workarounds are described below.

There are two methods of restricting access to a web site. First, you can use the HTTP authentication protocols to force a username/password dialog to appear when the user accesses a web page. Second, you can use a session-based approach where you ask for the username/password on a web form, and they log in using a session.

I believe SharePoint uses the first, but I'll answer both questions just in case.

HTTP Authentication

For HTTP authentication, the Java virtual machine is running in a separate process than the browser and does not have access to the username/password the browser used to authenticate with the web site. So when it connects back to the given resource, it pops up a dialog asking for this information again. This needs to happen once and then the Java virtual machine will cache the information as long as it is running.

The New Way

If you cannot upgrade or downgrade your user's Java version to a version that does not exhibit the authentication bug, the following workaround will work for HTTP authenticated web sites.

The basic idea is to proxy requests through a set of web pages secured by session-based authentication that exist in the same application space as pages secured by HTTP authentication.

In this scenario, the original request for the HTML page containing the applet is made to the SharePoint server. A unique ID (possibly just the SessionID) is created and sent back to the user as a parameter within the APPLET tag. Requests for all further resources are now made to web pages existing in an HTTP anonymous portion of the site. However, unlike the anonymous access above, these resources are only unlocked with a valid session ID.

So to retrieve the config.xml file, the URL would be something like:

/anonymous/GetResource.aspx?key=${user.key}&resource=config.xml

Since the session can store the username information retrieved from the initial request, this may also be able to be designed to access user-specific resources.

This is just as secure as the main SharePoint site, but requires extra coding on the server to make work. This is just a variation of the normal session-based authentication.

For more information on this approach, including sample files, please e-mail support.

The Old Way

Note: This solution has been obsoleted because security update # 832894 for Internet Explorer has removed the ability to pass username and password information within a URL. It is being kept here because it shows useful concepts that can be used elsewhere in Enterprise Tree Map.

Since URLs can contain this authentication information in the URL itself, you could embed the authentication directly into the URL. For instance:

http://user:password@www.myserver.com/GetData.aspx

Note that you don't have to re-write every URL you send out. You can leverage the expression language of Enterprise Tree Map to do the replacements for you. So you could define your data source using:

<dataModel>
   <parser type="csv"
           dataSource="http://${http.username}:${http.password}@
                       ${http.server}/GetData.aspx" />
</dataModel>

Then you could simply send the parameters as applet parameters:

   <param name="http.username" value="trevor">
   <param name="http.password" value="password">
   <param name="http.server"   value="www.myserver.com">

Since the only user who would receive this information is the user who logged in with that username and password, this is about as secure as the Basic HTTP authentication scheme (which I think you have to use anyway if you want to stick with AWT/JDK 1.1, since as far as I know JDK 1.1 didn't support NTLM or Digest authentication).

Session-Based Authentication

Session-based authetication is the second type of authentication. This type of authentication relies on the web server to manage the authentication information, and is the only type of authentication where you can effectively "log out".

When using session-based authentication, the user visits a login page where they enter their username and password. The web server then assigns them a session ID that is used to track them throughout the rest of the site. The session ID is the "key" that unlocks all their information, and effectively serves as a username/password combination (because the key space is usually fairly large and the session ID may also include IP address and other validation information, this method is more secure than Basic HTTP authentication).

Now the session ID must be passed back to the server on every request by the browser. This is done in one of two ways. One way is to embed the session ID into the URL, such as in mypage.aspx?SID=asdfh2348hf8. The second is to send the session ID as a cookie.

To get Enterprise Tree Map to work under this scheme, you need to pass the session ID through to the applet in some way. The easiest way is to pass the session ID as an applet parameter, either standalone or embedded into the URL. For instance, the RSS reader includes the following applet parameter:

<param name="config.treemap.dataModel.parser@dataSource"
       value="<?php echo "magpie/scripts/full-data.php?" .
                 session_name() . "=" . session_id() ?>">

This enables the data to be user-specific based on their session.

Likewise, we can use the same approach as in the HTTP authentication to re-write the URLs by passing just the session ID as a applet parameter:

<param name="user.sessionid"
       value="<%= Session.SessionID %>">

And then have the URL re-written like:

<dataModel>
   <parser type="csv"
           dataSource="/myapp/(${user.sessionid})/GetData.aspx" />
</dataModel>