Previous Topic

Next Topic

Book Contents

Book Index

System Internals - URL Crafting

MOVEit Transfer enables you customize user impressions and recognition of your site based on:

Note: System administrators can define custom themes, org contact information, org UI features, and so on. This is covered in SETTINGS > Appearance.

TransferTip See also the FTP Certs Tab in FTP - Configuration and the Multiple SSL Certificates below if you plan on hosting multiple organizations with different SSL certificates on your MOVEit Transfer server.

Org-Specific Sign-on Redirects (Passing HTTP Arguments for Multi-Organization Branding)

MOVEit Transfer enables you to combine org-specific schemes (WebUI look and feel) with crafted URLs. You define substrings within the URLs to enable users to sign on and access MOVEit Transfer secured content.

Syntax

orgid=<org-id-value>

Example

http://moveit.example.com?OrgID=2345

Description

The first page that appears to a user depends on the link they followed to the sign-on page. For most users, following links from an organization's main web site, the first page is the user's Home page. For users who follow links from notification emails, the first page is a page with details about a specific file.

Sign-On page appears as unbranded or branded.

Default (for example: http://moveit.example.com)

Branded by Org (for example: http://moveit.example.com?OrgID=2345)

Unbranded (Using the default MOVEit Transfer scheme)

An unbranded Sign-on page displays the MOVEit Transfer logo and contact information for the site provider. (SysAdmin users specify contact information when they create an org.)

An unbranded Login page is displayed by default unless particular Organizations brand this page. The URL to invoke this page is typically of this form: http://moveit.example.com

Branded (Specifying org ID name-value pair)

A branded Login page displays a particular Organization's logo, colors, and contact information. This information has been configured by an Administrator for that Organization through that Administrator's Settings page (SETTINGS > Appearance > Brand > Logo & Layout).

A branded Login page appears in either of the following cases:

Best practice: Hide this particular URL in a link to MOVEit Transfer from their main site.

URL Crafting (Additional MOVEit Transfer WebUI Arguments)

Argument Syntax

Description

quiet=true

Hide/suppress session time out or idle messages. (Proceed directly to sign-on screen instead.)

TransferTip You can use quiet to suppress server messages related to session timeout. This will get users to the sign-on page sooner and with fewer clicks.

contentonly=1

Hide header and banner logo from view. Ideal for when using MOVEit Transfer as embedded in a div or frame on a B2B or enterprise portal.

returnto=<url-to-trusted-host>

Define a fallback page. Allows user to return to a specified page or portal after closing the MOVEit Transfer session.

Note: In order to load the expected fallback page, the URL you provide must point to a machine configured as a trusted host. It must be present in the Trusted IP/Hosts List for the current Org.

arg12=downloaddirect

Download the specified file immediately or after authentication. Requires arg01=<MOVEitDMZ_FileID>

Suppress Session Expired Messages

Particularly with older versions of MOVEit Transfer, copying a URL for a specific user, folder, file or other MOVEit Transfer profile might cause MOVEit Transfer to sometimes display (correctly) that your session has timed out the next time that you try to access this URL. The display of this message, however, is often misleading, especially if you intend to use this URL in a permanent link tag on a public web site, such as a direct link to a support page.

To always suppress this session expired message, append the following code to any URL you want to make publicly available:

quiet=true

Content Only Display

Normal MOVEit Transfer pages include a header with banner logo, a user information bar, and a left-side navigation section, all of which allow the user to navigate to different pages within the application. Some companies might want to hide these sections, though, especially when MOVEit Transfer is used in a single sign-on system as part of a larger web application. To do so, append the following code to the URL the user clicks to visit MOVEit Transfer:

contentonly=1

This causes the header, user bar, and left-side navigation to be hidden for the rest of the session or until the code above is repeated with a value of 0. Because the value is stored in the session, only the first MOVEit Transfer URL invoked by the portal application must have this code.

This feature is designed to allow MOVEit Transfer to be used within an existing web application via frames or iframes. Therefore, when the contentonly flag is enabled, MOVEit Transfer disables its normal cross-frame scripting protection code and allows the interface to be loaded by external framesets.

Return-to Link

Normal MOVEit Transfer pages include a Sign Out link in the top menu bar, allowing the user to discontinue their session. When used in a single sign-on system as part of a larger web application, allowing the user to sign out is not a desirable feature. Instead, it is usually preferred to provide the user with a link back to the main web application. To have MOVEit Transfer replace the Sign Out link with a custom Return link, append the following code to the URL that the user clicks to go to MOVEit Transfer:

returnto=<your URL>

Replace <your URL> with the full URL of the web page that you want the user to return to. The URL must begin with either http:// or https://. Because the value is stored in the session, only the first MOVEit Transfer URL invoked by the portal application requires this code. However, MOVEit Transfer always uses the most recent value provided for the &returnto option.

Direct Download

Providing a special URL to end users forces them to initiate a (non-Wizard) download immediately after signing on (if not already authenticated). This procedure is typically performed by a MOVEit Transfer API application that creates its own notifications or web pages, but the same technique can be used by any application that can create a link for a user to click.

important Important: Download direct is available to browser sessions that are already authenticated (through SSO or an active session, for example). Otherwise, the download direct URL will require the user to input their password before the download is triggered.

Syntax

https://mynode.example.com/Username=<EndUser_Username>&arg01=<MOVEitDMZ_FileID>&arg12=downloaddirect&quiet=true

Example

https://transfer02.contoso.com/human.aspx?Username=dtaylor&arg01=9102186&arg12=downloaddirect&quiet=true

This crafted URL can be used with other crafted URLs such as Simple Single Sign-on Support or the MOVEit Transfer API session redirect to ensure that the user is signed on before attempting a transfer. Otherwise, the user will be prompted for a username and password.

—Where "910286" identifies the file to be downloaded.

Note: Different browsers might handle direct file downloads from MOVEit Transfer in different ways; sometimes files are automatically opened by the browser using the default application for that filetype, while other times the user is prompted to save the file before opening it. If the end users are not experiencing the desired behavior, add the argument noattch=0 to the direct download URL. This causes MOVEit Transfer to add a Content-Disposition: attachment header to the direct download response, which will cause some browsers to treat the downloaded file differently than normal.

Simple Single Sign-on Integration

To set up a single sign-on that integrates MOVEit Transfer into an existing portal environment, submit an HTML form that silently prefills a username and password. To do this, submit the form information, including the regular MOVEit Transfer URL, using the POST method.

Note: Previous versions of MOVEit Transfer suggested using the HTTP GET method to send the session id. Security best practices call for using the POST method instead of the GET method. If your web integration uses HTTP GET, and you want to continue to use the GET method, you must set the following registry entry to allow the continued use of this method.

Set the MOVEit Transfer registry value AllowInsecureQueryStrings to "1" to allow GET requests to include session IDs in URLs. For more information, see the Registry Settings section in the Technical Reference topic.

The original GET example suggested adding this snippet to the MOVEit Transfer URL:

&username=myusername&password=mypassword&transaction=signon

The following code shows an example of the POST method:

<BODY onload="document.forms[0].submit();">
<FORM action="https://moveit.yourcompany.com" method="POST">
  <INPUT type="hidden" name="transaction" value="signon"/>  
  <INPUT type="hidden" name="invisible-username" value="{myusername}"/>
  <INPUT type="hidden" name="invisible-password" value="{mypassword}"/>
  <NOSCRIPT>
   <P>Press this button to continue:</P>
   <INPUT type="submit" value="Continue"/>
   </NOSCRIPT>
</FORM>
</BODY>

Branded Redirect

Some installations want to use friendly names rather than OrgIDs in the URL sub path. For example, a provider wants users of Woodstock Bank to access MOVEit as https://www.example.com/woodstockbank and users of Pleasant Valley Credit Union access MOVEit as https://www.example.com/pleasantvalley. This can be a common scenario for service providers. It maximizes resource utilization while minimizing hosting and infrastructure-related costs.

To use friendly subpaths for your Orgs:

  1. Create a subfolder (on the SAME web server) for the firm. (for example, https://www.myorg.com/pleasantvalley)
  2. Create a new default.aspx file in that folder.
  3. Make sure the IIS web site/folder properties recognize default.aspx as the default doc in that folder.
  4. Copy/paste the following text into your new default.aspx file and make changes as necessary:

<% ' This redirect script sends users who type in "friendly" URLs 
' to the MOVEit front door with the appropriate parameters. 

'* * * * * * * * * * * * * * * * * * * * * * * * * 
'* Set your Organization's ID here!!! 
Dim OrgID as String = "1221" 

'* * * * * * * * * * * * * * * * * * * * * * * * * 
'* Set the official URL of your MOVEit DMZ here!!! 
'* (Make sure this URL has a VALID certificate.) 
Dim URL as String = "https://moveit.example.com" 

'* * * * * * * * * * * * * * * * * * * * * * * 
'* Do NOT modify the code below this line!!! 
Response.Redirect(URL & "?OrgID=" & OrgID) 

%>

Multiple SSL Certificates

To support having different SSL certificates for different MOVEit Transfer organizations, you must have a unique IP address / port combination, and SSL certificate, for each organization. For more information, see Feature Focus - Multihoming. If you are willing to share a named certificate across organizations, none of these extra steps are required.

For example, if SampleHoster wants to host secure.acme.com and ftps.whammo.com on the same MOVEit Transfer machine, each with a unique SSL certificate, then SampleHoster is multihoming. However, if SampleHoster wants to host vault.samplehoster.com and allow access to vault.samplehost.com/acme and vault.samplehost.com/whammo (one, shared SSL certificate), SampleHoster requires only:

Both of these configurations have been deployed by data centers and MOVEit Transfer supports both in production. The main reason cited for using individual SSL certificates for each organization is that it completes the branding experience. The main reasons cited for using single shared SSL certificate is that it reduces management effort and SSL certificate costs.