FAQ

Most Popular

MuseGlobal provides the following method for search and retrieval of EBSCOhost content: EBSCO Integration Toolkit (EIT) This is a SOAP-based Web Service approach which provides the optimal combination of performance and completeness. You can find the EIT Source Packages by searching in your Muse Console’s “Add Sources” section in the “IDs Containing” field for the term EIT. EIT SPs have Source IDs which start with the string EBSCOEIT. URLs: The HTTP Source Packages for EBSCO search on the URL http://search.ebscohost.com/. The EIT Source Packages use http://eit.ebscohost.com/Services/SearchService.asmx as the Home URL and Search URL. AUTHENTICATION: Authentication for the EBSCOEIT Source Packages is two-fold. 1) Authentication for search and retrieval can done by user/pw (with the USER_NAME and USER_PASSWORD fields of the profile) or IP (with the CUSTOM_PARAMETERS field of the profile). For search/retrieval authentication by IP, a value must be placed in the CUSTOM_PARAMETERS tag from the EBSCOEIT* source profile. Again, this is used to connect to and search a certain database. Using this IP authentication, you may be authenticated to a number of databases. Example : AUTH_TYPE=ip;IP_PROFILE=eit;IP_ADDRESS=1.2.3.4 where : IP_ADDRESS=your IP which authenticates to EIT. Please note that your EBSCO account must be specifically enabled in order to use of EIT. The user/pw used for connecting to http://search.ebscohost.com/ will not work for EIT. Also note that the IP_PROFILE will be either eit or eitws; — this string matches the 3rd section of your 3-part EIT authentication string (ex. s123456.main.eit or s123456.main.eitws). Please check with EBSCO if you are not sure which it is. 2) The aforementioned authentication by IP or user/pw gives us access to the EBSCOEIT API, but it does not provide successful link navigation on the record links obtained. For this, the PROXY_HOST and PROXY_PORT in the profile must be configured. IMPORTANT: authentication to EBSCO for link navigation is only done by IP. Example : proxy.you.com 9797 So, in conclusion, 2 IP authentication settings are needed: one (user/pw or IP) for accessing and searching the EBSCOEIT database desired and the other one (proxy IP) to successfully navigate on the record links obtained. Questions about your EIT account status should be referred to Gregory Julien [GregoryJulien@ebscohost.com].
Categories: Muse Search, Sources

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’.

Categories: General, Muse Proxy

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.

Categories: General, Muse Proxy

Load More

Latest

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).

Categories: Muse Search, Sources

The MNM entries can be set:
A) at the individual Source Package level
B) additional MNM entries can be set at the Application level

A) Setting MNM entries at the individual Source Package level:
The MNM entries can be set at individual Source Package level using the Muse Source Console (MSC) as follows:
– login into the MSC
– select an Application using the radio button
– select the “Sources” section
– go to “Configure” section
– click the “Advanced” button near the Source Package in the list that is to be edited
– the value for MNM must be entered in the “Link URLs” field

B) Setting additional MNM entries at application level
The MNM entries can be set at the Application level using the Muse Source Console (MSC) as follows:
– login into the 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 must be entered in the “Link URLs” field

Note*: The MNM entries at the Application level are additional to the ones set for individual Source Package level. So for a Source Package 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**: The MNM entries at the Application level are usually used when many sources at the Application level are using a WAM (Web Access Management) software such as ezProxy as this provides a way to add a MNM entry that is to be used by multiple sources. Except in the case of WAM software it is not recommended that MNM entries be set at the Application level.

Categories: Muse Search, Sources

You can use the following format:

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).

Categories: Muse Proxy, Usage

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.

Categories: General, Muse Proxy

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’.

Categories: General, Muse Proxy

Load More