Most Popular

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

The Flash and Java Applets resources are binary files which cannot be processed by any re-writing proxy, including Muse Proxy.

Flash and Java Applets may load in pages re-written by Muse Proxy as long as there are no absolute pathnames in URLs inside them or if there is an object parameter of the Flash or Java Applet, accepting its base URL. However, if the Flash or Java Applet contains links inside them, they will not be re-written.

In other words the Flash and Java Applets may display correctly in Muse Proxy re-written pages, but when an end-user clicks a link hidden inside the Flash or Java Applets it is possible it will go straight to the provider and may appear unauthorized.

Categories: General, Muse Proxy

The version of muse proxy can be found via putting in the following URL in an address bar on a browser such as FireFox or Internet Explorer:


In the above URL, PROXY_HOST is the server that is hosting Muse Proxy. PROXY PORT is the port that is running proxy. The default port for Muse Proxy is 9797.

The response is a XML message which is rendered raw by the browser. To correctly see the proxy version, view the source of the page (this is done differently in each browser) and search for the value of the field.

Please note that a dialog box may pop-up for entering UN/PW unless the IP where the request is coming from is allowed under the default section of the hosts.xml file under $MUSE_HOME/proxy/hosts.xml .

Categories: General, Muse Proxy
Tags: proxy, version

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.

Categories: General, Muse Proxy

Load More


There can be cases when you want that an Application Entry Point takes the end-user directly to the remote source without rewriting. For this a boolean flag is used for redirecting after the last but one request by dropping the proxy prefix and parameters and redirecting to the last URL value (after filling in the existent variables, if any) from the source profile.

The following directive must be added into the source’s XML profile:


[for more details check the Muse Proxy Sources Profiling.pdf manual, chapter 6.22 Redirecting to Remote Source]

Categories: General, Muse Proxy

Statistics are offered as a service to Muse Proxy customers, no matter they are locally hosted or on cloud. The statistics are generated from content of the Muse Proxy log files:
– access log (access.log).
– statistics log (MuseProxyStatistics.log).
More details about the Muse Proxy log files in the Muse Proxy Advanced Configuration manual, chapter “2.9 Log Files“.
For the instances hosted by MuseGlobal, there is nothing to be done, we take care of everything.
For the locally hosted instances, the main requirement is to upload from your server on a daily basis the 2 log files – access.log and MuseProxyStatistics.log – corresponding to the previous day, onto our FTP repository – ftp.museglobal.com – from where we will further pick them up for processing into the statistics platform.
The log files upload is carried out by means of scripts driven by the system’s scheduler/cron, depending on the Operating System. We provide such scripts.
The main requirement for the upload scripts is to have a single log file per day and with the date stamp in their filenames, e.g. access-yyyyMMdd.log and MuseProxyStatistics-yyyyMMdd.log. Refer to this FAQ for making the required logging changes.

Download the patch containing the necessary scripts from here. Copy the downloaded archive into ${MUSE_HOME} and extract it. The content is deployed into the following location on disk: ${MUSE_HOME}/proxy/tools.

Windows OS

Make sure that the patch is already deployed.

  • Edit the MuseProxyLogsUpload.xml file and replace the PLACE_HERE_THE_FTP_USERNAME and PLACE_HERE_THE_PASSWORD placeholders with the actual values as provided by the MuseGlobal Support Team.
  • Open a CMD window, change directory to %MUSE_HOME%/proxy/tools/ and run the MuseProxyLogsUploadAnt.bat script. This is for test purposes to make sure the upload script works.
  • Create a scheduler job in Windows to run the %MUSE_HOME%/proxy/tools/MuseProxyLogsUploadAnt.bat script each day after midnight, for example at 1:00 AM. There are many online tutorials for setting up a basic task, like for example here.

Linux OS

Make sure that the patch is already deployed.

  • Edit the MuseProxyLogsUpload.xml file and replace the PLACE_HERE_THE_FTP_USERNAME and PLACE_HERE_THE_PASSWORD placeholders with the actual values as provided by the MuseGlobal Support Team.
  • Open a shell session on the server, change directory to ${MUSE_HOME}/proxy/tools/ and change the permissions of the MuseProxyLogsUploadAnt.sh file to allow execution. Make the same for the ${MUSE_HOME}/proxy/tools/apache-ant-1.10.13/bin/ant file.
  • Edit the MuseProxyLogsUploadAnt.sh and make sure the value for MUSE_HOME points to the correct location on disk of Muse Proxy.
  • Run the MuseProxyLogsUploadAnt.sh script. This is for test purposes to make sure the upload script works.
  • Create a cron job to run the ${MUSE_HOME}/proxy/tools/MuseProxyLogsUploadAnt.sh script each day after midnight, for example at 1:00 AM.
Categories: General, Muse Proxy

To make sure Muse Proxy rewrites a website protected by Cloudflare the most reliable way is for the publisher to list the outbound IP address at Cloudflare. This is a must especially if the Cloduflare challenge is set to Interactive Challenge (the captcha-like one).

For publishers not intending to support rewriting proxies, if the publisher site is set up with a non-interactive JS challenge, then the Muse Proxy source profile can be configured using a base64 filter:

Use corresponding URL patterns here

Also some Cloudflare cases may require the following profile settings

Categories: General, Muse Proxy

Many websites implement security mechanisms to protect against spam and abuse from automated computer programs (bots), the most used solutions are the CAPTCHAs.

There are several CAPTCHA implementations available, Google’s reCAPTCHA being very popular.
The reCAPTCHA functionality is based on embedding the Google security check that is incompatible with any rewriting proxy software, which is the man in the middle between the user’s browser and the accessed website, thus considered a potential security issue. Because the domain of the rewriting proxy is different than the publisher domain registered for the reCAPTCHA, the security verification is failing.

However, if the publisher can register the domain of Muse Proxy for reCAPTCHA (ex. proxy.domain.com), the domain security verification will work. From our experience, there are few publishers that support the integration of the proxy domains with reCAPTCHA based on the proxy IP address. Technically they generate a reCAPTCHA key for each proxy domain and use it when the access is made from that proxy IP address.

For some publishers we found that they can disable reCAPTCHA on their site for the Muse Proxy users.

The answer to the question if Muse Proxy supports reCAPTCHA depends on the capabilities of the publisher platform: Yes, if the publisher can offer one of the two solutions described above, and No if there is no coping from the publisher.

Besides Google’s reCAPTCHA, there are other CAPTCHA solutions that can be found on publisher websites. If the publisher can disable the CAPTCHA for the Muse Proxy users, this is the most viable option. If this is not possible, as a last resort, we can try crafting inside the Muse Proxy Source Profile, a set of filters to process the CAPTCHA’s JavaScript coding to pass the domain verification or to redirect to a re-written version of the publisher domain being verified. But this solution takes a lot of development time and may not have a successful outcome and may even be against the terms of service of the publisher/CAPTCHA’s solution.

Categories: General, Muse Proxy

There are several methods for adding new resources into the Muse Proxy Application for handling the rewriting of vendor platforms, the recommended method is by using the Muse Proxy Administrator Console. The rewriting definitions for a vendor platform are stored in XML files, which we call Muse Proxy Sources.
Mainly the steps for adding a new Muse Proxy Source are:

  1. Identify the source profile in the existing repository from the EduLib website by accessing this link:
    Make use of the search functionality to narrow the results. Any term entered in the search box is searched in the source’s identifier and in the following field values from the source profile: NAME and DESCRIPTION.
    Once identified, click on the name link and a popup window will open with the details of the source’s profile. Click the Download Profile link to download the XML file.
  2. Access your Muse Proxy Administrator Console, the URL should be of the form:
    Login with the administrator user and the password that you configured during the setup.
  3. Navigate to the left menu Aplications item, Manage Applications link. Locate the Muse Proxy Application in use and click on the Sources button to access the list of installed sources.
  4. In the Sources page, click on the Create source from an existing profile icon, next to the Quick Filter search box.
  5. In the new page, upload the XML file downloaded at step #1. Upon succesfull upload, you are requested to specify the Source Identifier value, place here the file name without the .xml extension. Also you can change the default name and description values for the source. When done, click the Create button.
  6. The next step is to add the new source profile into a sources group. For doing this, in the Sources page click the Edit Sources Groups icon, next to the Quick Filter search box. In the new page click on the Sources icon from the Actions column, corresponding to the group in which to add the new source. By default only one group exists.
  7. In the new Sources Groups page, click on the plus (+) icon found next to the new source in the List of available sources column.
  8. Test by accessing a proxified link for the newly added resource. E.g. https://proxy.domain.com/applicationID?url=vendor_URL, where replace the hostname, applicationID and vendor_URL with the appropriate values.
Categories: General, Muse Proxy

Load More