Muse Proxy FAQ
Muse Proxy
http(s)://YOUR_PROXY_DOMAIN:PORT/APPLICATION_ID?url=PLACE_HERE_THE_URL_TO_PROXIFY
or
http(s)://YOUR_PROXY_DOMAIN:PORT/APPLICATION_ID?qurl=PLACE_HERE_THE_ENCODED_URL_TO_PROXIFY
where replace YOUR_PROXY_DOMAIN with the actual fully qualified domain name (FQDN) of your Muse Proxy system, PORT with the value of the port on which Muse Proxy runs, and APPLICATION_ID with the correct Muse Proxy application ID.
Example:
https://proxy.yourdomain.org/MuseProxyFoundation?url=https://www.jstor.org/stable/i20716440
or
https://proxy.yourdomain.org/MuseProxyFoundation?qurl=https%3A%2F%2Fwww.jstor.org%2Fstable%2Fi20716440
Important observation:
In order for these proxified links to work, a proper configuration dealing with the rewriting of that domain must be in place in Muse Proxy. Otherwise, if such a configuration does not exist, you will get a message from Muse Proxy like below:
The url parameter provided cannot identify a source. Your organization may not have authentication for that remote target, or a source has not yet been configured to access that remote target.
If you experience this, then further address with the administrator of your Muse Proxy system the need for adding such a configuration (in Muse Proxy terminology it is called a Muse Proxy Source Profile).Load More
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:
Type a) of proxy chaining is the most encountered in the Muse installations.
They are types of rewritten links handled by the ‘Navigation Manager’ web context.
A) Example of ‘Type 1’ rewritten URL:
http://navigationManagerHost:navigationManagerPort/com/site/?MuseProtocol=ProtocolValue&MuseHost=some.site.com
&targetSiteParameter1=targetSiteParameterValue1
...
&targetSiteParameterN=targetSiteParameterValueN
&MuseCookie=CookieValue&MuseReferer=RefererValue
&MuseAuthorization=AuthorizationValue
&MuseAuthorizationScheme=AuthorizationSchemeValue
&MuseProxyHost=ProxyHostValue&MuseProxyPort=ProxyPortValue
&MuseProxyPac=ProxyPacValue
&MuseProxyAuthorization=ProxyAuthorizationValue
&MuseProxyAuthorizationScheme=ProxyAuthorizationSchemeValue
&MuseCharset=CharsetValue&MuseUID=UIDValue
&MuseProxyAuthenticationToken=ProxyAuthenticationTokenValue
&MuseNavigationManagerMode=NavigationManagerModeValue&MusePath=PathValue
A rewritten link is of ‘Type 1’ format if it contains the Muse Navigation Manager authentication markers (MuseCookie, MuseReferer, MuseProxyHost etc. as CGI parameters) and if it does not contain the MuseSessionID marker in the path part of the URL.
The ‘Type 1’ URL can be manually created, automatically generated from a different application or can be generated using the “Utilities >> Rewrite URL” section from the Muse Proxy Administrator console. The latter is available only if the “Enable Type 1 Links” option is enabled in the Muse Proxy License Key File.
B) The ‘Type 2’ rewritten URLs are dynamical URLs associated with a navigation session managed by Muse Proxy. The ‘Type 2’ rewritten URLs are valid only for small periods of time (by default 30 minutes after they are last accessed), while the navigation session associated with them is still valid.
Example of ‘Type 2’ rewritten URL:
http://navigationManagerHost:navigationManagerPort/MuseSessionID=SessionIDValue
/MuseProtocol=ProtocolValue/MuseHost=some.site.com/MusePath
/targetSitePathPart1/.../targetSitePathPartN/?
&targetSiteParameter1=targetSiteParameterValue1
...
&targetSiteParameterN=targetSiteParameterValueN
A rewritten link is of ‘Type 2’ format if it contains the MuseSessionID marker in the path part of the URL.
The ‘Type 2’ rewritten links cannot be manually generated. They are 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;
– 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;
– all the rewritten links inside a rewritten page are rewritten links of ‘Type 2’.