FAQ

The MNM entries are set:
A) at individual Source Package level
B) at the Application level

To stop the rewriting for a Source Package, one must:

A) Remove the MNM entries at individual Source Package level
The MNM entries can be removed from the individual Source Package level through the Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button next to the Source Package to be edited
– the value for MNM entered in the “Link URLs” field must be empty

B) Removing additional MNM entries from Application level
The MNM entries can be removed from Application level using Muse Source Console (MSC) as follows:
– login into MSC
– select an Application using the radio button
– select the “General Settings” section
– go to “Navigation Management” section
– the value for the MNM at the Application level in the “Link URLs” field sould be empty, or that particular Source Package moved to the exclude section.

Note*: The MNM entries at the Application level are additional to the ones for individual Source Package level. So for each Source Package the the MNM entries set up for that Source Package plus the MNM entries set up at application level (A + B above) will be used.

Note**: in old Muse systems use for rewriting purposes the settings found in ${MUSE_HOME}/web/Users.properties. This method is obsolete now, so all the entries inside it of the form “application_id.navigationManagerMode” should be set to “none” (application_id.navigationManagerMode=none). This operation must be done after the values set here were merged with the ones from application level (see point B above).

The Navigation Sessions are used only by the ‘Navigation Manager’ Web Context (the Muse Navigation Manager component) to store useful data regarding a specific link navigation using a certain target site authentication context (cookies, referrer, next proxy access details, encoding etc.) through Muse Navigation Manager. This type of session is managed using an ID (named MuseSessionID) stored in the path of the Muse Navigation Manager rewritten links. This ID has associated a Navigation Session object at server side that stores the information needed to serve the requests for that Navigation Session (cookies, referrer, authorization, proxy, encoding, etc.).

A Navigation Session is generated by Muse Proxy in the following cases:
– when a user navigates on a ‘Type 1’ rewritten link there is generated automatically a redirect to a ‘Type 2’ rewritten link. The ‘Type 2’ rewritten link generated has associated a new Navigation Session;
– when a user logs into a Muse Proxy application and navigates on a Muse Proxy source link there is generated automatically a redirect to a ‘Type 2’ rewritten link. The ‘Type 2’ rewritten link generated has associated a new Navigation Session.

Many Navigation Sessions can be created for a single client, each corresponding to the authentication context of each rewritten target site. All the Navigation Session objects created for a Muse Proxy client are stored inside the Client Session object associated with that client. There is no limit set for the number of Navigation Sessions associated with each client.

In Muse, there are 2 types of proxy chaining:

a) “ProxyChaining” happens when the MNM chains with the proxy used for source authentication. In a Muse application where we have configured a MNM_HOST to re-write the record links and a PROXY_HOST to use for authentication we have the following scenarios:

1) If the MNM and PROXY fields have different values then at runtime when the end user navigates on a rewritten link the following happens:
– enduser makes HTTP request to MNM_HOST
– the MNM_HOST makes the HTTP request to PROXY_HOST, thus chaining.
– the PROXY_HOST makes the HTTP request to the native data source.

This scenario is described in the Muse Advanced Configuration.pdf document, chapter “Data Services IP Authentication” and applies in all ASP Muse environments where IP authentications are used. For example, this type of proxy chaining is used in all our hosted Muse instances.

2) If the MNM is the same as the PROXY_HOST then the proxy chaining does not occur anymore.

Note that the proxy chaining feature works only if the com.edulib.muse.proxy.filter.ProxyChain filter is enabled in the $MUSE_HOME/proxy/MuseProxy.xml configuration file.
Also note that the proxy chaining feature works with other proxies than Muse Proxy used for source authentication, e,g, when PROXY_HOST is other proxy than Muse Proxy .

b) Another type of proxy chaining is when the Muse Proxy is configured to use another proxy, meaning that it will forward all HTTP requests to the configured proxy. This happens when the following fields from the "$MUSE_HOME/proxy/MuseProxy.xml" file are configured:

</PROXY_PORT>



Type a) of proxy chaining is the most encountered in the Muse installations.