FAQ
FAQ by Product
Most Popular
&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’.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.
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:
http://PROXY_HOST:PROXY_PORT/ProxyInformation
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
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 .
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.
Load More
Latest
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.xmlfile and replace thePLACE_HERE_THE_FTP_USERNAMEandPLACE_HERE_THE_PASSWORDplaceholders with the actual values as provided by the MuseGlobal Support Team. - Open a CMD window, change directory to
%MUSE_HOME%/proxy/tools/and run theMuseProxyLogsUploadAnt.batscript. 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.batscript 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.xmlfile and replace thePLACE_HERE_THE_FTP_USERNAMEandPLACE_HERE_THE_PASSWORDplaceholders 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 theMuseProxyLogsUploadAnt.shfile to allow execution. Make the same for the${MUSE_HOME}/proxy/tools/apache-ant-1.10.13/bin/antfile. - Edit the
MuseProxyLogsUploadAnt.shand make sure the value forMUSE_HOMEpoints to the correct location on disk of Muse Proxy. - Run the
MuseProxyLogsUploadAnt.shscript. This is for test purposes to make sure the upload script works. - Create a cron job to run the
${MUSE_HOME}/proxy/tools/MuseProxyLogsUploadAnt.shscript each day after midnight, for example at 1:00 AM.
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:
Also some Cloudflare cases may require the following profile settings
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.
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:
- Identify the source profile in the existing repository from the EduLib website by accessing this link:
https://www.edulib.com/products/muse-proxy/support/muse-proxy-sources-profiles/
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:NAMEandDESCRIPTION.
Once identified, click on the name link and a popup window will open with the details of the source’s profile. Click theDownload Profilelink to download the XML file. - Access your Muse Proxy Administrator Console, the URL should be of the form:
https://proxy.domain.com/admin
Login with theadministratoruser and the password that you configured during the setup. - Navigate to the left menu
Aplicationsitem,Manage Applicationslink. Locate the Muse Proxy Application in use and click on theSourcesbutton to access the list of installed sources. - In the
Sourcespage, click on theCreate source from an existing profileicon, next to theQuick Filtersearch box. - In the new page, upload the XML file downloaded at step #1. Upon succesfull upload, you are requested to specify the
Source Identifiervalue, 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 theCreatebutton. - The next step is to add the new source profile into a sources group. For doing this, in the
Sourcespage click theEdit Sources Groupsicon, next to theQuick Filtersearch box. In the new page click on theSourcesicon from theActionscolumn, corresponding to the group in which to add the new source. By default only one group exists. - In the new
Sources Groupspage, click on the plus (+) icon found next to the new source in theList of available sourcescolumn. - 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,applicationIDandvendor_URLwith the appropriate values.
The short answer is Yes, Muse Proxy support TLS 1.2.
Muse Proxy runs on Java, hence it uses the Java Virtual Machine security settings, it does not rely on anything from the Operating System in this regard. Also it is not compiled with any specific SSL libraries versions like other software is.
Starting with Java 6 update 115, TLS 1.2 is available, and in Java 7 and 8 it is enabled by default.
Hence Muse Proxy supports TLS 1.2, and to be more precise, TLS 1.2 is supported since 2014 when we added support in the Muse Proxy configuration file to specify the SSL protocols that can be used both on the server end and on the client end (requests
against the sources).