Retrieving Browser

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
Joerg Hamacher
Posts: 48
Joined: Thu Feb 11, 2016 12:01 am

Retrieving Browser

Post by Joerg Hamacher » Thu Mar 03, 2016 2:30 am

Hi everybody,

how can I retrieve the browser in which the Web Page is running?
Many thanks in advance!
Joerg

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Retrieving Browser

Post by Stewart Marshall » Thu Mar 03, 2016 8:27 am

Hi Joerg

This information is available in the browser UserAgent string, accessible with a tiny bit of JavaScript in a widget.

http://www.w3schools.com/jsref/prop_nav_useragent.asp

We haven't made this available in VL because VL will manage browser differences for you. There shouldn't be a need for customers to manage it.

Is there a particular reason you need to distinguish between browser?

Regards
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

MarkD
Posts: 630
Joined: Wed Dec 02, 2015 9:56 am

Re: Retrieving Browser

Post by MarkD » Thu Mar 03, 2016 8:47 am

Browser and browser version recognition is a very dodgy art.

One example - If your page ever gets displayed by one of the many Windows applications that use the Trident/MSHTML control - see https://en.wikipedia.org/wiki/Trident_(layout_engine) - then the agent string will tell you things that are not correct, such as you are running in IE7 when you are not.

Same with embedded pages rendered by email clients on iOS and Android devices, etc. There are a lot more browser variations/specializations and embedded rendering situations around that just the standard IE, Chrome, Firefox and Safari browsers.

Joerg Hamacher
Posts: 48
Joined: Thu Feb 11, 2016 12:01 am

Re: Retrieving Browser

Post by Joerg Hamacher » Thu Mar 03, 2016 7:04 pm

Hi Stewart,

thank you for your answer.
One of the reasons is the different behaviour of #SYS_WEB.Close: this only seems to work in IE or EDGE (window occurs and browser closes when clicking YES) , in Chrome the browser closes immediately without showing the window , in Firefox (44.0) nothing happens at all.

Best regards,
Joerg

User avatar
Jiri
Posts: 44
Joined: Thu Feb 11, 2016 11:41 pm

Re: Retrieving Browser

Post by Jiri » Thu Mar 03, 2016 9:04 pm

#SYS_WEB.Close is a good example. If you have a Logout logic in your application, in browsers supporting this feature is best to close the winows after Logout logic is finished. In Firefox it is nasty, the best available solution is navigate back to a Logon screen.

Joerg Hamacher
Posts: 48
Joined: Thu Feb 11, 2016 12:01 am

Re: Retrieving Browser

Post by Joerg Hamacher » Fri Mar 04, 2016 12:00 am

Maybe it is better if I get more specifically...

We have a huge iSeries (5250) ERP system completely adapted for use in aXes.
Since all the logic is RPG / iSeries based we are in doubt what will happen if the users press typical browser buttons like "refresh", "back" or "close".
Database inconsistencies would be the consequence of such behaviour...

That's why we thougt to embed the aXes application into a web page (using "web page"-control) to keep control over the browser events.
We like to prevent the users from closing the application or refreshing pages by simply ignoring these browser events (that means: how can we explore which browser buttons and actions were fired and how can we react to this event?) and also prevent them from using aXes application with a firefox browser(that means: how can we detect the browser type and version?).

Best regards,
Joerg

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Retrieving Browser

Post by Stewart Marshall » Fri Mar 04, 2016 10:44 am

Hi Joerg

"We like to prevent the users from closing the application or refreshing pages"

In short, you can't. There is no realistic way of doing this. This is a very good thing indeed!! Most web site developers are good people, but there are a few whose motivations are less friendly. It's the same reason the local file system isn't available.

The #sys_web.CloseQuery event can be used to prompt the user when they try to navigate to another page, but they can still carry on after this if they want to.

You'd need a proper Windows application to achieve the level of control you're talking about, and even then Task Manager could still shut it down. And even if we use Windows security to prevent this, there's still the power socket on the wall.

The only practical solution is to make sure that the code executing on the server protects the database as best it can.


Regards
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

Post Reply