Creating Splash Pages

Technical Brief: Creating Splash Pages
SGOS 3, 4 Series
Creating Splash Pages

What are Splash Pages?
Many organizations would like to send out notices to their employees, ensure that the employees see the corporate Internet Use policy, or direct the employees' first Web request to the corporate intranet Web site. A splash page is the page to which the employees would be redirected. This document describes how splash pages can be implemented on the ProxySG appliance.
Behavior Summary
For the implementation described in this TechBrief: Users will see one splash page per interval as defined by the administrator If supported by the user agent, the splash page will be replaced by the requested content
System Requirements
This TechBrief describes how splash pages can be implemented using features introduced in the ProxySG. It makes use of specific features not available in previous versions, including: Additional substitutions (explained later)
This implementation uses redirection to a virtual "splash" domain. The secure proxy appliance must receive requests destined for this domain.
Limitations
Splash pages can only be delivered to clients requesting HTML content over the HTTP (or terminated HTTPS) protocol. In the implementation described in this note, requests made through other protocols or for other types of content will be unaffected. Mechanisms to control the presentation of the Splash page are not secure, and rely on plain text cookies. The user agent must therefore be configured to accept cookies. Setting short absolute expiry times is susceptible to clock drift problems that may result in continual splashing. For the ProxySG, the splash domain must be DNS resolvable.
Overview
Splash pages are implemented by: 1 Defining a custom exception page. The exception uses HTML to define a splash exception page that will be displayed to users. On this page you can place a description of the corporate Web access policy, provide notification messages for users, or other appropriate information. The splash exception page should also contain a mechanism to obtain the originally requested content. 2 Defining policy to determine whether or not the client has already been splashed and to display the splash exception page as appropriate.
Defining the Splash Exception

The Splash exception page is defined using the exception feature introduced in the ProxySG. You should define your exception page using your favorite HTML source editor, after reading through the sample source and the rest of this technical brief. Briefly, exceptions have a hierarchical structure. We define an exception by defining a name, and various other values that distinguish our exception from the rest. In particular, we should be aware of the following exception features: ID This is the name we will use to reference the exception in policy. In our example, we will define this to be "splash". The fully qualified name of the exception will be "user_defined.splash". Format This is the format used by non-HTTP protocols when they return the exception. Since we cannot use splash pages for non-HTTP protocols, we do not define or use this format for the splash exception. HTTP Format Contact This is the format used by the HTTP protocol when it returns exceptions. This format is usually defined using HTML, and may contain CPL substitutions This is the value of $(exception.contact), the standard exception page substitution for help desk contact information.
HTTP Format
Here is an example of a corporate splash page. The HTML source we will use to define the HTTP format for a splash exception page is shown on the next page:
<html> <head> <title>Sample Splash Exception Page </title> <meta http-equiv="Content-Type" content="text/html; charset=iso8859-1"> <meta http-equiv="Refresh" content="10; url=$(server_url)"> </head> <body bgcolor="#FFFFFF"> <center> IMPORTANT NOTICE System maintenance is scheduled for Sunday July 17, 2:004:00 am EST. To report any conflicts with the scheduled maintenance, $(exception.contact) Click <a href="$(server_url)"> here </a> to continue. INTERNET USAGE IS ROUTINELY MONITORED AND LOGGED. Your IP address: $(client_address) Your username: $(user.name) </center> </body> </html>
Important Notes
1 The amount of time before the splash page is refreshed with the original content is determined by the first value supplied to the Refresh tag's content= option (line 6), and is set to 10 for this example. 2 CPL (Content Policy Language) substitutions are used in the sample splash page to report the user's name and IP address, and to include the URL for the original content. You may want to use other CPL substitutions in your splash page. See other Blue Coat documentation for further information about the list of CPL substitutions available. 3 The splash page uses $(server_url) for access to the original content because a rewrite action must be used to recover the original URL when serving the splash page. The Policy section explains further details. 4 This sample page uses $(exception.contact) to include a link to email the service desk. You will need to customize this link to provide the correct contact information if you choose to include such a feature in your own splash page. 5 This exception definition references $(user.name), which implies that we expect an authenticate() property to be applied somewhere in the policy. If policy does not cause an authentication to occur before the exception is set, then remove this reference from the exception format.
6 This sample page states "Internet usage is routinely monitored and logged". That is assumed true as part of the standard corporate practice specified elsewhere in the policy rules, and merely reflects the type of text likely to appear in practice. Setting the splash exception has no side effect on logging behavior. See the Variations section for an example of how to couple logging policy to the splash page. 7 This sample splash page includes an explicit link that users can use to fetch the original content if automatic refresh is not supported by the user agent.
Loading the Exception

The exception definition can be loaded through the Blue Coat Command Line Interface (CLI), either as an inline definition or through an installable list. For example, to create an exception named "splash" as described above using an inline definition in the CLI, you would enter the following commands once in enable mode:
SG3000#config t SG3000#(config)exceptions SG3000#(config exceptions)create splash ok SG3000#(config exceptions)edit splash SG3000#(config exceptions user-defined splash)inline http format xxxeof <insert or paste the HTML source for the page here> xxxeof SG3000#(config exceptions user-defined coach)exit
Testing
To test the exception page use the following steps: 1 Log in to the Blue Coat Management Console 2 Select Statistics -> Advanced 3 Click on the "Exceptions" link. 4 Click on the "View Exceptions Configuration" link Under the heading User-Defined Exceptions, you should see an entry for the splash exception. Clicking on the "View Settings" link will display the exception settings as entered at the CLI (command line interface). Clicking on the "View Sample HTML" link will show a sample of the exception page, with some sample data values used for any defined substitutions.
Policy
The next step is to define a Blue Coat policy to control the presentation of the splash page. Here is the theory of operation: 1 An artificial "splash domain" is used to keep track of the splashed state using cookies.
2 When a request arrives, a policy determines if the client has already been splashed by looking for a splash cookie. When the client browses to a new domain, the splashed cookie will not be present in the request. In this case the splash cookie is set for the new domain and the client is redirected to the splash domain with a URL in which the original URL is encoded. 3 In the request to the splash domain, the presence of a splash cookie in the request indicates that the client has already been splashed. If the client has been splashed, the original URL is recovered from the request URL and the client is redirected back to the original location. If the splashed cookie is not presented in the request to the splash domain, the client has not been splashed, so the splashed cookie is set and the splash exception page is returned. The splash exception page has a mechanism to obtain the originally requested content. 4 When the client once again requests the original content, the request is accompanied by the splash cookie and is allowed through (subject to other policy). A suitable set of conditions for determining when to return the splash page follows. The first condition is used to ensure the client is expecting HTML content, which is a requirement for delivering the splash page. As well, we ensure that the Web request is not destined for the address of the management console by adding console_ access=no to the condition.
; We can only splash when the user is expecting HTML content, ; and we will not splash explicitly proxied administrators. ; define condition can_splash console_access=no response.header.Content-Type="text/html" end
The next condition tests for the presence of the splash cookie, which indicates that the user has already seen the splash page.
; true if we find the splash cookie ; define condition splash_cookie_is_present request.header.Cookie="splashed=yes" end
Note: This example uses "splashed=yes" for clarity. You may want to use a more obscure cookie description in real deployments.
If a request is not for the splash domain and the splash cookie is present, we let that request through. Otherwise, if we can splash, the following action is invoked:
; For each new domain visited, the user is redirected to ; the splash domain, to see if they've already been splashed. ; define action check_for_splash ; Preserve the original URL as part of the redirection, so ; we can do the check and use the original URL to then get the ; content. ; Set the cookie now so next time they will get through. ; ; Use $(url.cookie_domain) to reduce the number of sub-domains ; that get checked. ; redirect( 302, "(.*)",
"http://splash.policyexample.bluecoat.com/Splash?$(1)" ) set( exception.response.header.Set-Cookie, \ "splashed=yes; expires=$(cookie_date:minutes.add(5))$(url.cookie_domain)" ) end
Note the use of the line continuation character '\' which must be the last character on the line and follow space or tab.
This action matches the full URL and then preserves it in the query portion of the redirect URL. It also sets the splash cookie, so that after the splash check, a request for the original content will not trigger the splash check again. This example sets the cookie to expire in 5 minutes. This duration is useful when doing initial testing, but is subject to clock skew problems. Other settings are more likely for deployment, such as expiration at midnight. If you choose to use short expiration times for testing, first ensure that the test station's clock agrees with the time on the secure proxy appliance. See the Setting the Splash Interval section for further details.
Note: The expiration time of the cookie is set for the individual domains. The expiration time will also be set for the cookie in the splash domain. If no expiration time or maximum age is specified, the cookie will last for the browser session. This may result in missing splash opportunities (if the session lasts longer than the splash interval) or splashing more often than required (if the sessions are shorter than the splash interval).
The next condition will test for URLs directed to the splash page, a URL within our virtual "splash" domain.
; Anything directed to this domain might result in a splash page. ; The original URL will be in the path. ; We'll never emit an IP address, so there's no point in forcing ; an RDNS check. ; define condition URL_is_splash_page url.domain.no_lookup=splash.policyexample.bluecoat.com/Splash end
Note: The URL we use in the example, splash.policyexample.bluecoat.com/Splash, must be defined for your installation. Requests for the domain "my_splash_domain.com" must arrive at the secure proxy appliance that issued the challenge. For the ProxySG, the domain must be resolvable by DNS queries. For testing purposes "www.bluecoat.com/Splash" will work.
When this condition is true, we will check for the splash cookie. If the splash cookie is present we redirect the client once again, using the original URL recovered from the request URL.
; This action is used to redirect the client back to the ; originally requested content, ; after a check with the splash domain showed the client had ; already been splashed. ; define action redirect_post_splash redirect( 302, "http://www\.my_splash_domain\.com/Splash\?(.*)", "$(1)" ) End
If the splash cookie is not present in the request to the splash domain, policy will prepare to return the splash page exception by recovering the original URL and setting the splash cookie for the splash domain using the following action. The splash page uses the result of the rewrite by referencing $(server_url) for the original content.
; At the Splash Domain during a check, we received the original ; URL in the query. ; This rewrite gives us back the original URL. ; define action prepare_to_splash rewrite( url, "http://www\.my_splash_domain\.com/Splash\?(.*)", "$(1)" ) set( exception.response.header.Set-Cookie, \ "splashed=yes; expires=$(cookie_date:minutes.add(5))" ) End
In this example we set the expiry for the cookie in the Splash domain to be the same as the expiry of the cookies in the original domains. This may be inappropriate for many deployments. See Setting the Splash Interval for a discussion of the issues involved in setting expiry times. Finally, the policy layer that controls the various states of the splash mechanism, using these conditions and actions is:
; Policy Layer for Splash Page control <Proxy splash> ; ; ; ; ; ; ; ; ; ; To prevent infinite loops, the first thing we do is trap requests for the splash page Each time the user visits a new domain, they get redirected to the splash page. If they've already been splashed, redirect them back to where they were going. A cookie has already been set for that domain so they will get through. condition=URL_is_splash_page condition=splash_cookie_is_present \ action.redirect_post_splash(yes)
; Otherwise they have not been splashed, so splash them. ; We rely on the splash page definition to get them back ; afterwards. ; Note that the URL is in the form ; ; http://splash.policyexample.bluecoat.com/Splash?original_url, ; ; so the URL must be rewritten to strip off the splash URL ; prefix. ; The exception page format uses $(server_url) substitutions ; to pick up the rewritten URL. ; condition=URL_is_splash_page action.prepare_to_splash(yes) \ exception( user_defined.splash ) ; Next we check for requests that already have the splash cookie ; set. ; condition=splash_cookie_is_present OK
; ; ; ; ; ; ; ; ; ; ; ; ;
just let them through Otherwise, if the content type is appropriate, we check to see if we should splash by redirecting the request to the splash domain. If the user has already been splashed the splash cookie will be offered there. Otherwise the user will be splashed. In either case, they will eventually re-request the original content. We set a cookie for the original domain during the redirection, so that the post-splash check request for the content will get through. condition=can_splash action.check_for_splash(yes)
Notes: 1 The label "splash" that follows the layer type "Proxy" in this example is valid CPL. This label acts like a comment, but unlike comments it is preserved in the listing of the currently installed policy. It also makes it easy to locate and reference layers used for specific purposes. 2 To let users who present the splash cookie through, we use a rule with the keyword OK. This is a CPL no-op token and could be omitted in most cases. Use OK rather than allow so as to not override previous access policy that might have denied access for other reasons (for example, based on the client's subnet). 3 Below is an example of the policy:
; Condition definitions ; We can only splash when the user is expecting HTML content, ; and we will not splash explicitly proxied administrators. ; define condition can_splash console_access=no response.header.ContentType="text/html" end ; ; ; ; ; Anything directed at this domain might result in a splash page. The original URL will be in the path. We'll never emit an IP address, so there's no point in forcing an RDNS check. define condition URL_is_splash_page url.domain.no_lookup=splash.policyexample.bluecoat.com/Splash end ; true if we find the splash cookie ; define condition splash_cookie_is_present request.header.Cookie="splashed=yes" end ; Policy Layer for Splash Page control <Proxy splash> ; To prevent infinite loops, the first thing we do is trap
; requests for the splash page ; ; ; ; ; ; ; ; Each time they visit a new domain, they get redirected to the splash page. If they've already been splashed, we need to redirect them back to where they were going. A cookie has already been set for that domain so they can get through next time. condition=URL_is_splash_page \ condition=splash_cookie_is_present \ action.redirect_post_splash(yes) Otherwise they have not been splashed, so splash them. We rely on the splash page definition to get them back afterwards. Note that the URL is in the form http://splash.policyexample.bluecoat.com/Splash?original_url, so the URL must be rewritten to strip off the splash URL prefix. The exception page format uses $(server_url) substitutions to pick up the rewritten URL. condition=URL_is_splash_page action.prepare_to_splash(yes) exception( user_defined.splash )
; ; ; ; ; ; ; ; ; ;
; Next we check for requests that already have the splash cookie ; set. ; condition=splash_cookie_is_present OK ; just let them through ; Otherwise, if the content type is appropriate, we check to see ; if we should splash by redirecting the request to the splash ; domain. If the user has already been splashed the splash ; cookie will be offered there. Otherwise the user will be ; splashed. In either case they will eventually be re-request the ; original content. ; ; We set a cookie for the original domain during the redirection, ; so that the post-splash check request for the content will get ; through. ; condition=can_splash action.check_for_splash(yes) ; check for need to splash ; If the splash page contains embedded URLs, there may be issues ; pipelining them so we turn pipelining off. ; <Cache splash> condition=URL_is_splash_page pipeline(no) ; Action definitions ; IMPORTANT: This example sets cookie expiry in both the content
; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;
and splash domains to 5 minutes. The user will be splashed roughly every 5 minutes, with a maximum time between splashes of 10 minutes (the sum of the two cookie expiries). This is only useful for testing purposes since it is subject to clock skew issues between the client and the Proxy SG. To splash once per session, remove the expiry setting. To splash once per day, or according to some other schedule, set the expiry accordingly. For each new domain visited, the user is redirected to the splash domain, to see if they've already been splashed. define action check_for_splash Preserve the original URL as part of the redirection, so we can do the check and use the original URL to then get the content. Set the cookie now so next time we'll get through. Use $(url.cookie_domain) to reduce the number of sub-domains that get checked. redirect(302, "(.*)", "http://splash.policyexample.bluecoat.com/Splash?$(1)") set(response.header.Set-Cookie, "splashed=yes; expires=$(cookie_date:minutes.add(5))$(url.cookie_domain)") end
; At the Splash Domain during a check, we received the original ; URL in the query string. ; This rewrite gives us back the original URL. ; define action prepare_to_splash rewrite( url, "http://www\.my_splash_domain\.com/Splash\?(.*)", "$(1)" ) set(response.header.Set-Cookie, "splashed=yes; expires=$(cookie_date:minutes.add(5))") end ; This action is used to redirect the client back to the ; originally requested content, after a check with the splash ; domain showed the client had already been splashed. ; define action redirect_post_splash redirect( 302, "http://www\.my_splash_domain\.com/Splash\?(.*)", "$(1)" ) end
Setting the Splash Interval

The splash interval is determined by the lifetime of the splash cookies, set in the prepare_to_splash and check_ for_splash actions in this implementation. There are two options here: To splash on each browser session, omit any expiry or max-age components when setting the cookie. To splash again after a relative interval (for example, an hour from now), relative cookie expiry times
must be generated. CPL provides the $(cookie_date) substitution to supply the current time in the format required by Set-Cookie headers, and a set of modifiers to produce offsets from the current time. For example, set(response.header.Set-Cookie, "splashed=yes; expires=$(cookie_date:hours.add(1))") sets a cookie that expires 1 hour, relative to the clock on the secure proxy appliance. See the following table for further examples.
Note that the lifetimes of the cookies set in the splash domain and the content domains overlap, so the user may go the sum of the splash domain cookie lifetime and the content domain cookie lifetime between splash page presentations. You may therefore wish to set shorter lifetimes for the cookies set in the content domains. For example, setting a splash domain cookie expiry of 10 minutes and a content domain cookie expiry of 2 minutes, would mean that a user might go 12 minute between splashes.
To splash the user each Monday morning, the first of the month, or on some similar interval, absolute cookie expiry times must be generated. CPL provides the $(cookie_date) substitution to supply the current time in the format required by Set-Cookie headers, and a set of modifiers to advance to the next desired time interval. See the following table for examples.
This table gives several examples of modifiers that could be used in $(cookie_date:modifier). See the CPL Reference manual for more details. modifier :minutes.add( 15 ) :hours.add( 2 ) :day.add( 1 ) :next_date( 2:00 ) :next_date( 00:00 ):next_date( 2:00 ) :next_date( 00:00 ):add.days( 1 ):next_date( 2:00 ) :next_date( Mon 2:00 ) :next_date( last 22:00 ) :next_date( 15 Tue 2:00 ) effect expires in 15 minutes expires in 2 hours expires in 24 hours expires at 2 am expires at 2 am tomorrow expires at 2am the day after tomorrow expires at 2 am Monday morning expires at 10 pm the last day of the month expires at 2am the third Tuesday of the month Note that the third Tuesday of the month must be between the 15th and 21st. The expression advances zero or more seconds to the 15th of the month, and then advances zero or more seconds to Tuesday, then advances 0 or more seconds to 2 am. :add( 2 ):next_date( 2:00 ) :days.add( 2 ):next_date( 1 ) if it's earlier than midnight, expire at 2am, if after, expire at 2am the following day. expires at midnight the last day of the month, except if we're within 2 days of the last day (in which case we get till the end of next month)
Note: Setting the expiry time is done with reference to the secure proxy appliance's clock, but is interpreted relative to the user's clock. Therefore, using this technique to set short expiry times is subject to clock skew problems. Suppose, for example, that the cookie expiry is set to 5 minutes into the future. This is done relative to the clock on the secure proxy appliance. If the client's clock is more than 5 minutes ahead of the secure proxy appliance's clock, from the client's view the cookie will already have expired when it is set, with the result that user will be splashed continually. We would recommend against using short expiry times for this reason. To use short expiry times for testing, first ensure that the test station's clock agrees with the time on the secure proxy appliance.
When setting relative rather than absolute expiry times, remember that the lifetimes of the cookies in the individual content domains and the splash domain will overlap, so the maximum time between splashes may be the sum of the two expiry times. To minimize this, you may choose to shorten the expiry of the individual content domains relative to the splash domain interval.
Deployment
The <Proxy splash> layer is probably best defined through the Local policy file to avoid accidental changes to the logic that implements splashing. This layer is a boilerplate for most splash page applications and does not require user modification. The Local policy file should follow the VPM file in the policy file order. The parameters of the splash behavior that are of interest to users include: The contents of the splash page - set through the exception page format The time before the splash page is replaced with the originally requested content also set through the exception page format (although this could also be set in the policy actions, see Variations) The splash interval - determined by the cookie expiry time The splash domain - this domain is mentioned several times in the policy conditions and actions. It is unlikely to change after initial deployment
This implies that we can provide the VPM with control over the splash page behavior by defining the following actions in the VPM, rather than in the local policy file: check_for_splash prepare_to_splash
Remember that to avoid compilation errors, any conditions or actions should be defined in the VPM before they are referenced in the Local policy file.
Testing
To test your splash policy: 1 Set a short splash interval (the 5 minute interval used in the sample is appropriate) 2 Browse to various domains The splash page should be presented after each interval, as specified.
Variations
This TechBrief cannot cover all of the variations that might be required in the field, nor all of the various CPL features that might be used to support field requirements. Here we present just a few of the simpler possibilities.
Requiring Explicit Acknowledgment

The sample splash page automatically redirects the user to the requested content. To require users to take an explicit action (clicking on a link) to view the originally requested content, remove the following line from the splash page format.
<meta http-equiv="Refresh" content="10; url=$(server_url)">
Recall that the sample page already includes a link to the original content in the body of the message. Ensure that such a link appears somewhere in the body of the page.
Click <a href="$(server_url)"> here </a> to continue.
Note that the URL used in this link is again the server_url, since this is the original URL recovered from the request URL by a rewrite action.
Using Non-Exception Based Splash Pages

Rather than defining the splash page as an exception that can be served directly from the secure proxy appliance, some clients may prefer to load the splash page onto a server. To begin, all occurrences of
splash.policyexample.bluecoat.com/Splash
need to be customized to point to the correct location. As well, the policy rule
condition=URL_is_splash_page action.prepare_to_splash(yes) \ exception( user_defined.splash )
should be changed to:

condition=URL_is_splash_page action.splash(yes)
To decide what the splash action should do, consider how the user will subsequently retrieve the originally requested content. There are three alternatives: 1 The user must re-issue the original request manually, for example using the browser's Refresh button. The splash page text should include appropriate instructions. In this case, there is no point in preserving the original URL in the splash request, nor in recovering it from the request. The splash action should be:
define action splash redirect( 302, "(.*)", "splash.policyexample.bluecoat.com/Splash" ) ; the splash page URL End
2 Policy adds a Refresh header to the splash page response. The Refresh header uses the recovered original URL. The content will be refreshed after the interval specified in the header. The splash page should still contain instructions for the case when the user agent does not support refreshes. The splash action would be:
define action splash redirect( 302, "(.*)", "splash.policyexample.bluecoat.com/Splash" ) ; the splash page URL set(response.header.Refresh, "10; url=$(server_url)") end
3 In order to provide access to the originally requested content, custom software could be loaded on the server to generate the appropriate embedded link or refresh header from the query portion of the request. If the splash page contains links to embedded content, pipelining the embedded content may cause issues for some deployments. Turn pipelining off for the splash page by adding:
; If the splash page contains embedded URLs, there may be ; issues pipelining them so we turn pipelining off. ; <Cache splash> condition=URL_is_splash_page pipeline(no)
Splashing Only Specific Users

If you want to limit splashing to specific user populations, define a condition such as:
define condition splash_groups group=splash_group1 ... End
and add this to the can_splash condition definition:

; We can only splash only the selected users, and ; only when the user is expecting HTML content. ; define condition can_splash condition=splash_groups response.header.ContentType="text/html" End
If the <Proxy splash> layer is defined in the local policy file, a somewhat more efficient alternative is to guard the layer with the new condition:
<Proxy splash> condition=splash_groups
The splash_groups condition might be the defined in the VPM and the rest of the changes kept to the Local file.
Splashing Different User Populations

If you want to present different splash pages to different user populations, you will need to duplicate most of the conditions, actions and rules for each. It may be simplest to treat each population in its own layer, using the technique described above for Splashing Only Specific Users.
Conclusion
This TechBrief has provided the information and steps to create a splash page for an enterprise network environment. A splash page can be used to communicate company news, corporate announcements and policies to an entire organization. For additional information regarding the Content Policy Language (CPL) or other variables please refer to your Blue Coat documentation or contact a Blue Coat Systems engineer in your area.
Blue Coat Systems, Inc.

www.bluecoat.com
Sunnyvale, CA USA // +1.408.220.2200
Corporate Headquarters
EMEA Headquarters
Hampshire, UK // +44.1252.554600
APAC Headquarters
Hong Kong // +852.3476.1000
Copyright 2009 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications are subject to change without notice. Information contained in this document is believed to be accurate and reliable, however, Blue Coat Systems, Inc. assumes no responsibility for its use. Blue Coat, ProxySG, PacketShaper, ProxyClient and BlueSource are registered trademarks of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are the property of their respective owners. v.TB-SPLASH_PAGE-v3-0609

Creating Splash Pages

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Creating Splash Pages

Загружено:

Авторское право:

Доступные форматы

Technical Brief: Creating Splash Pages