Note: This information applies to Vista 3+ as well as Vista 4+/Campus Edition 6+.
Usually, a WebCT proxy tool is invoked by a user clicking a hyperlink from the course home page (or course content home as it's called in Vista 4.0/CE 6.0). From there, the proxy tool calls the authentication module, which does whatever it needs to do to authenticate the user and redirects that user to a third party application. This is usually enough if you're simply logging users in and redirecting them to a secure portal. But what if you want do something more complicated?
For example, suppose you want to create a custom, wizard-like HTML form interface to allow your proxy tool user to interact with a third party web application. You could redirect the user to another web server that hosts your custom script. This might be entirely acceptable to you if your organization has the hardware and software to accommodate this.
Alternatively, you could develop some fairly complicated authentication module interaction using auth mod callbacks and passing lots of HTML strings to setResponseContent. This is less than ideal from a debugging standpoint (code, recompile, redeploy, restart WebCT, ad nauseum).
A Better Way
If you've ever seen a proxy tool launched in its own window outside the WebCT frameset, you probably noticed a URL in the location bar similar to the following:http://<host>:<port>/webct/ptLaunch.dowebct?id=4031001
The idparameter specifies the unique identifier of the proxy tool instance. Any authenticated user with sufficient permissions can launch that proxy tool instance using that URL.
This means that, given the URL and the correct ID, course designers can embed a proxy tool directly in a course home page and even in a learning module. For example, a designer could embed a proxy tool in a section's header like this:
<object
data="/webct/ptLaunch.dowebct?id=4031001"
type="text/html">Failed to embed proxy tool</object>
The proxy tool launches automatically when the user navigates to the section and is displayed inside the home page's header. (The "Failed to embed proxy tool" message only appears if the browser fails to embed the proxy tool for some reason.)
For a PowerLink?developer, an obvious question might be, "how do I get a proxy tool instance's ID without actually clicking the link?" In order to be truly useful, you want to be able to get the ID programmatically.
Getting the Proxy Tool Instance ID
When you invoke a proxy tool, an HTTP request is sent to the proxy tool's authentication module. You can get that request using the auth mod's getRequest method. If the proxy tool was invoked from within a section, the proxy tool instance ID can be retrieved from the request's id parameter. If the proxy tool was invoked from My WebCT?, you can get the proxy tool instance ID from the request's tid parameter. The code in your auth mod might look something like this:
public void login()
{
HttpServletRequest \_request = super.getRequest();
String ptid = \_request.getParameter("id");
if(ptid==null)
{ ptid = _request.getParameter("tid"); }
...
}
Now What?
Once you have the proxy tool instance ID, you can pass that information to an external application, which can then invoke the proxy tool using the ptLaunch.dowebct URL. You can also embed links to the proxy tool in the HTML content generated by the setResponseContentmethods. (Of course, the user still needs to have a valid WebCT session in order for these to work.) You can include additional information when the proxy tool is invoked and retrieve it from the HttpServletRequest in the authentication module. Then you can generate different content based on the information passed in the request. For example:
public void commit()
{
HttpServletRequest _request = super.getRequest();
String ptid = _request.getParameter("id");
if(ptid==null)
{ ptid = _request.getParameter("tid"); }
}
String pageId = \_request.getParameter("page_id");
...
String ptLink = "<a href=\"/webct/ptLaunch.dowebct?id=" + ptid +
"&page_id=" + pageId + "\">Link to page " + pageId + "</a>";
...
super.setResponseContent(contentBefore + ptlink + contentAfter);
return true;
}
As mentioned earlier, using setResponseContent to generate complex, dynamic content can be tedious to code and debug and WebCT does not currently support server-side scripting. However, you can use the Velocity template engine to greatly simplify the creation of dynamic pages from within authentication modules.
 | This article originally authored by Paul Monk on the WebCT DevNet
|
This page
Other pages
Account
