Please do not use to report errors- use your regional help desk.
Please mark posts as being for RPG or RDMLX (LANSA) developer.
To subscribe by email, display this forum, scroll to the end and select ‘Subscribe Forum’.
Is it possible to have more details on the following sentence in the Getting Started with LongRange LANSA | System Requirements: “You can not use Web Authentication or a proxy server.”?
Web authentication
• What is restricted: Web server authentication (IIS on Windows and/or Apache on IBM i) and/or LANSA for the Web authentication?
• Do LRUAVAIL/LRULOGON reusable parts apply to both IBM i and Windows? What type of authentication is used by them?
Proxy server
• If it is restricted on IBM i, I don’t understand what was said in Tips, Techniques and Examples | Some basic security configuration combinations by MarkDuignan » Wed Aug 22,012
The wording in the Getting Started guide is possibly heavy handed. What it is trying to express is that the client is not a web browser – just as a client for web services (say) may not be web browser. Therefore your L4Web server instance cannot respond the client as if it was a web browser. This means browser based authentification techniques, redirections and proxy server ‘tricks’ are all likely to cause issues with the client.
The diagrams use reverse proxy servers – which is a recommended and supported technique for use with aXes-LongRange. Personally I have never seen this type of configuration used with a L4Web instance - people tend to use the ‘model B’ configurations instead – but I can see no particular reason why you could not get it to work.
The security model for mobile apps is an evolving area – so for the moment the recommended technique is as provided in the shipped examples.
This allows for more flexibility – for example by registering ‘devices’ by their GUID and making users sign on/off on a transactional basis it is possible for many users in a warehouse (say) to securely share an iPad. It also makes it easy to deregister a device (say) instead of a user. I don’t think there is a one size-fits-all solution for mobile solutions in this area. The missing part in the shipped example is how to validate a user against Windows – as opposed to using a custom user or device based models.