UAG and your own code!
One of the greatest aspects of UAG's customizability is the ability to add your own code into the mix (and not just the look and feel of it!). I've already discussed some ways to do this, like a custom endpoint detection script, and adding JavaScript code to the portal's HTML, and now it's time to talk about injecting stuff into the login mechanism.
For this, UAG allows for a customization referred to as "PostPostValidate". As the name implies, it refers to adding code that is executed after UAG validates a user's identity. This entails creating a special file with standard ASP code that can do whatever you need. It can run any regular ASP command, such as response.write or response.redirect, and retrieve standard ASP server variables like QUERY_STRING and REMOTE_ADDR, but the cool trick is that it can also collect certain session parameters and act on them.
To create a custom post-post-validate file, create a new, blank text file, and name it according to your trunk name, type and with the suffix of "postpostvalidate.inc". If, for example, you have named your trunk "OurPortal", and it is an HTTPS trunk, the resulting file would be "OurPortal1postpostvalidate.inc". For an HTTP trunk, use 0 instead of 1.
Save the file in the folder <UAG Path>\Von\InternalSite\Inc\CustomUpdate, and activate the UAG configuration. You can start with a completely blank file, and as you change it going forward, you don't need to activate again with additional changes to the content of the code in the file (because ASP is server-side code, and is re-parsed on the fly).
The things you can do with this file are endless. I'm going to discuss some of them in a sec, but this is a good opportunity to mention that while this is a supported functionality of UAG, Microsoft will not be able to support your own code, beyond providing some generic code samples. The suggestions I'm about to make here, including the code snippets, are just suggestions, and this blog post is not an official documentation of any kind.
The advantage of code that is running in this context (of postpostvalidate.inc) is that it is called as part of the user's login, and thus has access to the user's session data in its entirety. By using the GetSessionParams object, you can retrieve any and all of these, and act on them. Those params (parameters) are everything the UAG detection module collects off a client, and include tons of stuff - the computer's name, domain membership, OS, browser version and much more.
Here's a piece of code to collect all of the parameters:
<% Set policies = GetSessionParams(g_cookie, empty) For Each param in policies.ParamVec response.write param.name & ":" & param.value & "<BR>" Next %> |
The 1st thing that comes to mind is simply collecting this info. As you may know, even though UAG logs every session, it does not actually record the session parameters of each user, and you can normally only see those while a session is active (using the Web Monitor). Based on the above code, you can simply dump the content of the entire thing into a text file, an Access or SQL Database, or other data collection mechanisms. You could even use it to generate alerts (by using the CDO object for sending Email or SMS, for example).
Another thing you can do is provide the user with info, like the name of the server he is connecting to (in case you are using a server array), or show some welcome and/or instructional text. You could create code that detects and redirects users to another page, or portal, based on some parameter/s. The possibilities are endless!
One thing that's important to keep in mind is that UAG has special code that "includes" this file automatically, once UAG detects it has been created. UAG also includes many other files, with many functions. This is good, because it gives you access to those functions (if you know then, and know what they do), but it also may cause a conflict, if you try to reuse the name of a function or a variable that's already in use.
Another thing to note is that ASP is not always the easiest thing to debug, and you can't just install Visual Studio or debugging tools on UAG and start hacking away (Installing additional software on UAG is not supported…remember?). One thing that could be helpful is to turn on full ASP debugging messages on IIS. To do so:
1. On the UAG server, open a CMD prompt
2. CD to %systemdrive%\inetpub\adminiscripts\
3. Run the command adsutil.vbs set w3svc/AspScriptErrorSentToBrowser true
4. It should return with “true”:
Now, in case of an error in your code, the browser will print out the name of the file, and line, where the issue is. Keep in mind, though, that this is considered to be insecure, so make sure you set it back to FALSE when done with your development.
In case you are interested, here are some external content that discuss and suggest more creative uses for PostPostValidate:
https://technet.microsoft.com/en-us/library/dd282925.aspx
https://technet.microsoft.com/en-us/library/dd278156.aspx
https://www.forefrontsecurity.org/ArticleViewer/tabid/131/articleid/59/Default.aspx
Have fun!