Hiya Jacqueline,
As far as my understanding goes, it's like this:
1. libURL looks after any internet requests from an LC app to an internet
server and has basic support for manual proxy configuration via the HTTPProxy
function. e.g. "set the HTTPProxy to "127.0.0.0:80""
However, a lot of user computer connections to proxy servers we're experiencing
these days are configured via .pac files - which is basically a file on the
local subnet that 'points to' the correct proxy settings - allowing for a
'lookup' sequence to occur. Sometimes the .pac config also triggers system
level authentication before providing full access to the requesting app.
.pac file configuration is actually much better, as it allows auto lookup of
proxy details on the host computer which shields the user from having to :
a. know what a proxy server is in the first place
b. know how to configure it, and
c. what the details actually are for their specific situation
..... if the user machines are NOT configured, via .pac files, they usually
require the user to manually enter proxy server details into software that
requires access.
The ideal user experience of course, is complete invisibility of all this.
Sometimes, both methods are available. We are finding that the manual
configuration method is being 'phased out' in the schools we are shipping to
due to the onset of iPads that are more easily configured by .pac method.
2. LC / libURL support is OK, for manual configuration, after which point, all
internet requests are sent via that method. All sounds easy enough right?
The gotchya is, that LC does NOT currently have the capability to query a .pac
file configuration at the system level, and therefore auto-populate the
httpproxy details. So, users are immediately locked into scenario outlined in
point 1 above.
In addition, there are significant anomalies with how the http proxy function
and/or subsequent file up/downloads work on mac/win when met with the myriad of
different proxy server software that exists in different organisations in an
authentication session.
We have launched into a nation wide distribution with internet dependant
features, and have found considerable variance with basic connectivity support
in the app when using these functions. Our users are not avid computer users,
and are now having to fill out multiple forms before being able to use the
software for the first time. It's a big hurdle for most of them.... and that's
when everythings actually working!
Eventually, it all gets up and running, but our support queue is usually
running at capacity, and it's rarely to do with our actual software, and almost
ALWAYS to do with the proxy support or configuration process.
I would recommend:
1. Putting a LOT of thought and execution into your startup UX to ensure
maximum simplicity and timing of events that are likely when a user starts up
the software in a proxied environment. Error messaging, progress bars, simple,
visually comfortable forms to fill out...etc...
2. Researching and testing as many different proxy configurations with your
resultant model to check for variance / timeouts etc..
3. Making friends with a few experts in the IT departments of organisations
you're shipping to so that testing is even possible. An internal test server
just doesn't cut it.
4. Keeping an eye on .pac support process for LC (Trevor DV has already been
down this path with the GLX App framework, but it's yet to appear anywhere
else, including LC proper)
BOTTOM LINE, any internet dependent software running in an organisation is
HEAVILY dependent on the whims of the IT team(s) controlling the network
configuration it's running in.
As developers in LC, we are pretty much limited to what LC has in the box for
proxy support. In addition, because our functionality does not run in a
browser, we're subject to the usual overriding assumption in these
organisational configurations that any app not 'known about' is evil.
It'd be great to see a solid solution / external / plugin that thinks this
stuff through properly emerge for us all from somewhere, the two key
requirements being:
- UX optimisations / templates for developers making internet aware apps
requiring user based proxy authentication - preferably with .pac and manual
config workflows covered
- Addressing the myriad of variables that exist across MAC/WIN network
configurations and the common suite of proxy servers that are likely to be
encountered, some of which do NOT provide the 'standard' handshake expected,
creating anomalies / errors in the connect process.
Easy huh?
I'd love to see how other education community focussed solutions have dealt
with this problem for internet dependent features and proxy support previously.
We can't help wondering if we're missing something totally simple in our rather
challenging process here.
Hope that sheds light.
Cheers,
A.
On 18/03/2013, at 3:33 PM, J. Landman Gay wrote:
> On 3/17/13 9:06 PM, Anthony Howe wrote:
>
>> If you are distributing cross platform software to users inside
>> organisations that use firewalls and proxy servers, and then intend
>> to attach an internet based registration service to your product,
>> using LiveCode as the underlying application engine do it, I strongly
>> suggest signing up for a life membership to your nearest acupuncture,
>> remedial massage, and zen meditation centre as quickly as possible.
>
> Could you say a little more about the problems you had? I don't want to hit
> the same wall.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
