Sometimes it's convenient to link directly to pages in EKP from external systems. For example, if you have a course with ID MY_COURSE
, you could link to the course catalog page from a page on your company intranet by using a URL like the one below.
/ekp/servlet/ekp?TX=FORMAT1&CID=MY_COURSE
However, if you create a link in this way then the visitor will see only the course catalog page, not the usual EKP navigation frames, so she will not be able to explore EKP, or even log out.
With a little more work, it's possible to create a URL that will let you link to the same page in such a way that it's displayed with the standard navigation frames. You do this by using a URL that follows the pattern shown below.
/ekp/servlet/ekp/pageLayout?mainSrc={URL-of-target-page}
You need to replace {URL-of-target-page}
with the actual URL of the target page. However, this URL needs to be URL-encoded. It's beyond the scope of this blog post to fully explain how URL-encoding works, but basically it involves replacing special characters with an encoded form that consists of a percentage symbol (%) followed by two letters or digits. For example, the slash character (/) is replaced by the percentage symbol followed by the digit 2 and the letter F. Here is a more detailed explanation of URL-encoding.
To return to our original catalog page example, the URL-encoded form of the target URL is as shown below.
%2Fekp%2Fservlet%2Fekp%3FTX%3DFORMAT1%26CID%3DMY_COURSE
Once this is substituted into the URL that displays the navigation frames, the final full URL is as shown below.
/ekp/servlet/ekp/pageLayout?mainSrc=%2Fekp%2Fservlet%2Fekp%3FTX%3DFORMAT1%26CID%3DMY_COURSE
The same technique can be used for any internal EKP page that can be linked to directly.
2 comments:
This likely works well, but the problem we encounter when using this method is the the user is confronted with the login page.
We are using SSO. One would think that it would pass you through anyway becuase the system already has the login credentials.
You don't mention which kind of SSO you are using, i.e. Integrated Windows Authentication or Web-based single sign-on.
The technique described in the post should work fine with Web-based single sign-on, but currently does not work with Integrated Windows Authentication. However, feel free to submit an enhancement request.
Post a Comment