Teach a server to fish

Artikel
06/14/2011

In my recent blog post about AppWrap and SRA, I discussed how one can use these mechanisms to instruct UAG to alter textual content “on the fly”, as UAG passes a file to the client’s computer. I also mentioned that this could be used to overcome a situation where UAG fails to sign a certain link. This, indeed, is a common situation we handle in UAG Support, but as I said then, using SRA or AppWrap this way is not always the best approach.

The thing about manually fixing missed links is that you might be tempted to simply add the missing HAT signature into a URL reference, and that’s a double-edged sword. That HAT signature might change in the future, making your SRA not only invalid, but also damaging, in some cases (as it could redirect to the wrong serve or application). Also, if the content itself is dynamic, you might not be able to find a way to address it at all. Lastly, if you have a complex application, it might require many changes, forcing you to write and test a lengthy SRA file, or change it whenever some guy from accounting decides he needs another view for his table.

So…there is a better way. As you may know, the SRA engine looks for specific HTML tags in the content, and uses that to recognize URLs. For example, when looking at this:

<input type="hidden" name="hrweb" src="/formtool/listitems.asp" />

It identifies this as an “input” tag, and is programmed to look for the SRC attribute and sign it. If, however, the data is formatted this way:

<input type="hidden" name="hrweb" value="/formtool/listitems.asp" />

UAG will not handle it, because the value attribute is not set to be analyzed this way. This configuration, of what to look for and where, is part of the default SRA configuration file, and the good news is that you too can control it! If, until reading this post, you may have tried doing a search-and-replace for that text directly, you will now be able to TEACH UAG to do the right thing in a way that globally affects every page that behaves this way.

UAG knows which tags to handle and how to handle them using a list, which is contained in the default SRA configuration file (these are also referred to as an AAP file, by the way). This list has the names of the various tags (img, iframe, frame, form etc), with each tag having a list of attributes that UAG is to look for. You can find the default list of tags on your own server, in the file <UAG Path>\Von\Conf\Websites\<Your Trunk>\Conf\WhlFiltSecureRemote_HTTPS.xml (or HTTP, if this is not a secure trunk). Here’s a snip:

<ATTR>profile</ATTR>

</TAG>

<NAME>iframe</NAME>

<ATTR>longdesc</ATTR>

<ATTR>refreshURL</ATTR>

<ATTR>expandLink</ATTR>

</TAG>

<NAME>ilayer</NAME>

<ATTR>background</ATTR>

</TAG>

<ATTR>dynsrc</ATTR>

<ATTR>longdesc</ATTR>

<ATTR>lowsrc</ATTR>

<ATTR>usemap</ATTR>

</TAG>

As you can see, each HTML element is identified by “<NAME>”, and then, the possible attributes that it can handle are in “<ATTR>” tags. By inspecting the default file, you can identify which attributes UAG identifies by default, and by customizing the file, you can teach it to work with other tags and attributes. For the example above, you would start by looking for the text “<NAME>input</NAME>” in the default file, to see how UAG handles it. What you would find is this:

<NAME>input</NAME>

<ATTR>usemap</ATTR>

<ATTR sign_abs_path="false">value</ATTR>

</TAG>

Interestingly, you can see that the 3^rd attribute here IS value…but the “sign_abs_path” attribute sets UAG to only sign paths that are ABSOLUTE. If the URL was a full URL (https://www.createhive.com), UAG would sign it, but our path is relative, so it will be ignored. In this case, all we need to do is adjust that attribute and remove that tag. Naturally, as always, editing the default files in UAG is a no-no. Instead, we just copy that section of the document into our CustomUpdate folder, and activate the configuration! Here’s the syntax of the final custom SRA file:

<PARSER_HTML>

<NAME>input</NAME>

<ATTR>usemap</ATTR>

<ATTR>value</ATTR>

</TAG>

</PARSER_HTML>

</WHLFILTSECUREREMOTE>

Using the same format, you can also introduce completely new tags that UAG is not aware of, but always start by checking if UAG already has definitions for them. If you don’t, and it has, your file may conflict with the default and cause UAG to miss even more links. If there ARE existing definitions, you do need to mirror them in your custom file. For example, let’s say that my application has a link like this:

<iframe src="A.html" name="window" align=center action=”/save.aspx”>FrameMain</iframe>

By default, the iFrame tag is configured for the attributes longdesc, src, refreshURL and expandLink, but not the Action attribute. We need to add it, but keep the other configurations, so the resulting SRA file would be:

<PARSER_HTML>

<NAME>iframe</NAME>

<ATTR>longdesc</ATTR>

<ATTR>refreshURL</ATTR>

<ATTR>expandLink</ATTR>

<ATTR>action</ATTR>

</TAG>

</PARSER_HTML>

</WHLFILTSECUREREMOTE>

This is, of course, just the tip of the iceberg with regards to things you can do with SRA. For example; you may have noticed that this SRA starts with “Parser_HTML”? That’s because UAG defines different tags for different parsers. There’s also a separate set for CSS, JavaScript, VBScript, and there’s also a <PARSER_EXCEPTION> piece, which allows you to configure attributes that should be skipped altogether. There’s also a list of “EVENT_HANDLERS”, which define JavaScript commands that UAG should look into for URLs. For example, some apps use the “OnClick” JavaScript method to define an action for a button or link, instead of the regular HREF. The SRA has a special line for this action, and others, which you might also need to modify or expand!

Have fun!

Props to Shea B!

Freigeben über

Teach a server to fish

Zusätzliche Ressourcen