Publisher Site Login authentication restricts access to a digital issue or archive to users who access the magazine via a link from a restricted page, typically accessible through a login form on the publisher’s website. That page is considered the referrer URL.
Multiple referrer URLs may be specified for a given title. However, if multiple titles are accessible via the same referring page, GTxcel can not distinguish access restriction for each title. Therefore, users would have access to all titles listed on that referring page.
If a user tries to view the digital magazine without having come first from the referring URL, he/she will be redirected to a specified alternative URL.
Alternatively, publishers may redirect the user to a subscription page or landing page of their choice.
Note 1: A referrer URL is considered valid if it matches the root of the specified referring URL.
Example: The specified referrer URL is: https://www.abc.com/profile
then: https://www.abc.com/profile/archives and https://www.abc.com/archives/issue would also be considered valid referrers because the root of the URLs matches the specified referrer URL values.
However, if the specified referrer URL is http://www.abc.com/profile/archives
then https://www.abc.com/profile would not be a valid referrer, as it is missing the last part of the referrer (/archives).
Note 3: Referring URL should always be HTTPS.
Update Oct 2020
New browsers enforce a stricter referrer default policy (strict-origin-when-cross-origin). In order for PSL pages to work clients need to set the referrer-policy to the previous default value (no-referrer-when-downgrade) when redirecting to us. There are a few options when doing this.
Option 1 – Set policy as http header:
This option is useful for dynamically generating pages and would likely require a developer to implement.
Option 2 – Set policy has page metadata tag:
<meta name=”referrer” content=”no-referrer-when-downgrade”>
This option is the easiest to implement, as it only requires adding this meta-tag to the page with the link to your digital edition.
Option 3 – Set policy as attribute on a-tag:
<a href=”http://url-to-webreader.com” referrerpolicy=”no-referrer-when-downgrade”>
This would require adding an attribute to every link to your digital edition.
Please note, if you have an app with GTxcel that also utilizes Publisher Site Login, this change will need to be made on BOTH your digital edition login page as well as the app login confirmation page.
Publisher Site Login Access is ideal for those publishers who already have a log in feature on their website and wish for people to access the digital edition through the publisher’s log in page. In addition, publishers who do not wish to or are not able to provide subscriber email addresses to GTxcel can create a mobile version of their sign-on page that GTxcel will use in the app to grant access.
Using this mechanism provides users with access to all issues available in the app; there is no ability to restrict access to specific issues that have been converted for the app.
- Association publishers
- Publishers using their own user authentication access to the web digital edition
- Publisher login URL – Must be secure (https) & mobile optimized and must NOT contain any methods of subscribing or registration. (sign-in only) – Here is an example of an acceptable login page: https://apps.naspa.org/lex/default.cfm
- Success URL (This page will not actually be displayed to the app reader, but will be used by the app to recognize that the publisher has verified this reader.)
- Test account, including username and password. This is required to provide to Apple as part of the submission process in order for the app to be approved
Guidelines for Mobile Optimized Sign-In Page:
Mobile browsers require simple and clean HTML in order for the page to display and function properly. Often times, the sign in page that is used for standard web browsing will not render on mobile devices. Some publishers choose to create a new sign in page specifically for mobile devices, per our recommendation. This alleviates the need to try to balance the elaborate HTML that many publishers prefer to have on a standard web browser with the limitations of mobile browsers.
Here are some guidelines for creating your mobile optimized sign-in page:
- Create simple HTML.
- Remove any extra or unneeded div tags and tables.
- Do not use HTML that is created from programs such as Microsoft Word or Dreamweaver as these tend to create HTML that is not clean and simple.
- Do not include Flash on this page, as it will not display on mobile devices
- Test the sign in page on both a mobile Safari browser and a mobile Android browser to confirm that the page displays and functions as expected.
- Must be secure (https)
- May NOT contain methods for subscribing or registering.
- Should only contain option to log in (per Apple & Amazon policies).
- Example of a good sign in page:
- If you are using the user agent as part of the login page, be lenient about how you grant access. The internal webview used by the app is a slightly different browser string than mobile safari. Please consult a resource like http://www.useragentstring.com/pages/Safari/ to determine the appropriate user agent specifications to use. At the time of this writing, the user agent for mobile safari and the internal webview are similar to:
Mobile Safari: Mozilla/5.0 (iPod; U; CPU iPhone OS 4_3_5 like Mac OS X; ja-jp) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5
Internal iOS Webview: Mozilla/5.0 (iPod; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Mobile/8L1
Guidelines for Success URL:
The success URL is a critical piece to making the Publisher Site Login Access work correctly. Here are some items to consider when providing the success URL:
- The success URL must be a static URL, meaning it cannot change from user to user.
- The success URL cannot be the same as the sign in page. Pages that dynamically display content depending on a users sign in status will not function in the app correctly.
- If any type of identifier is used in the success URL, it must be included after the base URL.
- Examples of a good success URL
- The success URL for the sign in page example in the section above appears as:
- Examples of a good success URL
User installs app with an immediate view of all cover images. Each cover image will display a preview button.
From a technical standpoint, the way our apps determine login success is as follows:
- When a user attempts to access any portion of the app that contains restricted content, the app opens a web view containing the login URL
- Every time the user visits a new page within the web view, the app reads the URL
- If the URL matches the success URL using the regular expression ~ /^$success_url/ we immediately close the window and grant access to all restricted content within the app. Note that we only check that the URL visited by the user starts with the success URL that was provided. So if your success URL is http://website.org/success, we will still grant access to http://website.org/success/myaccount, http://website.org/success.html or http://website.org/success?key=value&key2=value