Disable browser buttons

[pbrad]

Hi again,

Just a couple of quick enhancements to your form. The submit button is missing the value (<input type="button" name="b" value="PutButtonTitleHere"onclick="startAware(); return false;"> )

Also, the username and password are currently left in the form so if the user leaves his/her computer, someone else could come along and re-click on the form and login using these credentials. To solve this problem, add the line:

document.forms [0].reset();}

after the window.open line in the function and before the </script> line.

Of course, the url parameters in the app showing the password are still a deal breaker for me right now.

Cheers,
Pete

[aware_support]

We'll see if we can hide these parameters... Will let you know

[aware_support]

Apparently it's impossible to hide parameters using the above method, but here is another idea:

1. Start your own chromeless window using whatever means you have, for example, using window.open(...)
2. Implement your own login form inside this chromeless window
3. Make sure that the names of the input controls that collect user name and password are exactly the same as those required by Aware IM URL:
a) userName
b) password
4. Post the form to the Aware IM logonOp.aw URL:
logonOp.aw?domain=MyDomain&testingMode=false

Once Aware IM receives this post it will read parameters from the form, so the post will be equivalent to this URL:
logonOp.aw?domain=MyDomain&testingMode=false&userName=blah&password=blah

This will then open the application within the same window where the post
came from, i.e. the chromeless window. The browser should NOT display
form parameters in the URL.

[pbrad]

Hi,

As mentioned earlier in this thread, the problem with this approach it that users will invariable bookmark the page that has the logon form in it and when revisiting the bookmarked page, it will open up in a regular browser.

Granted I am not a java programmer and I don't know the peculiarities of the new v4 ajax urls but I regularly strip out various parameters in php and asp by getting the querystring and rewriting the page or redirecting to the same page or another url with only portions of the original querystring.

Failing that, would it not be possible to make a variation of the logonOp.html page that would likely be written in java that receives the post from an outside form page, gets the querystring and passes the parameters to the same javascript that is in the existing logonOp.html page and then runs the same function that is in the logonOp.html page. I am not explaining this correctly but hopefully you get the picture. Basically instead of entering the login info of the logonOp.html page you pull that info from the url and then automatically pass everything through to the logonOp.aw page. This would be run on a 'BeforeShow' page event to prevent page flickering as the first page did it's thing.

Perhaps this approach might work?
Cheers,
Pete

[aware_support]

To me the bookmarking problem is a very minor one and the approach described before is the same for version 4 as for version 3.

Your solution with redirection and stripping off parameters shouldn't work in theory because the browser will just display the URL being passed to the window.open () function - it will not care how the server handles this URL. The only way for the browser not to display the parameters is to post them as part of the form. However, if you are posting it as part of a form there is no way for you to indicate that the result should be in a chromeless window - you cannot control it from the server, it MUST be on the client. When you are posting the form you can specify the target where the result will be displayed and you can specify a blank window, but you cannot specify a chromeless window as part of the target, unfortunately!!! The only way to specify a chromeless window is to use window.open function in the JavaScript and this rules out form posting and introduces the URL display problem.

Therefore, your second idea will not work either.

The bottom line is that one has to choose the lesser of two evils if one wants to display a chromeless window. One evil is seeing password as part of the URL and another evil is users bookmarking the wrong login page. To me the second evil is very minor and I would definitely go for it. Other than that there is not much we can do. All these issues have nothing to do with Aware IM - these are just side effects of the browser technology and there are some limitations that you have to live with for the time being.

[pbrad]

Okay,

It is not a deal breaker so let's just settle on solution #2. I am going to have a go at making my idea work. If I am successful I will let you know. If not, I think that it is time to let this one go.

cheers,
Pete

[pbrad]

Okay, one last kick at this horse.

It turns out that this is not really an issue at all and works fine. I just headed down the wrong road when I was working with the logon.aw url instead of the correct logonOp.aw.

You can indeed post to the logonOp.aw page from an external form and open the app up in a chromeless window at the same time.

Add a script in the head of your external html page:

<script language="JavaScript">
function doSubmit() {displayWindow = window.open('', "newWin", "scrollbars=1,menubar=0,toolbar=0,resizable=1,location=0,status=0");
document.submitForm.submit();document.submitForm.reset();}</script>


and in the body of your page put the following code to build the form:

<form action="http://xxx.xxx.xx.xxx:8080/AwareIM/logo ... domain=xxx" method="post" name="submitForm" target="newWin" id="submitForm">
&nbsp;&nbsp;
<table width="402" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="27" background="images/LoginTop.jpg">&nbsp;</td>
</tr>
<tr>
<td background="images/LoginBody.jpg"><p class="Text"><br />
&nbsp;&nbsp; <span class="style3">Username:</span> &nbsp;
<input name="userName" type="text" size="24" />
&nbsp;&nbsp;&nbsp;</p>
<p><span class="Text"> &nbsp;&nbsp;&nbsp;</span><span class="style3">Password:</span><span class="Text">&nbsp;&nbsp;
<input name="password" type="password" size="24" />
</span> </p>
<label></label>
<p> &nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type="button" name="button" value="Submit" onclick="doSubmit()" />
</p></td>
</tr>
<tr>
<td height="10" background="images/LoginBottom.jpg" class="TextSmall"></td>
</tr>
<tr>
<td height="10" class="TextSmall"><p><br />
</p></td>
</tr>
</table>
</form>


You can either point back to this page on logoff or use the logoff.jsp page.

Unfortunately, you can only use this for a published app, not when it is in testing mode as it doesn't seem to accept testingMode=false but no big deal.

If you still want to use the method put forth by support earlier, I would suggest that you prevent the user from bookmarking the logonOp.aw?domain=xxx page as it will open up in a new browser next time. One way to do this is to add the following script to the logon.html template in the Tomcat/AwareIM folder. This prevents the user from being able to access the right click context menu in order to add the page to their favourites.

<script type="text/javascript">

var msg="Right click disabled";

function click(e) {
if (document.all) {
if (event.button == 2) {
alert(msg);
return false;
}
}

if (document.layers) {
if (e.which == 3) {
alert(msg);
return false;
}
}
}

if (document.layers) {
document.captureEvents(Event.MOUSEDOWN);
}
document.onmousedown=click;

</script>

I must admit though that one problem with using this url is that if the user mis-types their credentials, they are returned to the logonOp.aw page without the domain specified. This is fine if your business space is the default space, otherwise, they are going to be out of luck when trying to login. (and you are going to receive a phone call or email that your system is broken)

Cheers,
Pete

[tford]

This works perfectly! Thanks for sharing, Pete.



Tom

[aware_support]

Regarding the problem of losing business space - this has been reported elsewhere and it should be fixed in the brand new build 1135

[pbrad]

Much appreciated.

Pete