(sorry about cross-posting, but hey, different servers!)

I frequently get a requst from our help-desk, and I guess it might be of
interest to everyone here too.

Once we have created an account on our web-apps for a customer, we then
email the customer and get them to telephone the help-desk.  When the do,
the help-desk tells them the url to get to the web application, and asks
the user what password they want.

the help-desk then enable the account and set the password, and tell the
user how to login.  Once the user is in, the help-desk wlk them through
using the system, and finally advise them to change their password so the
help-desk don't know what it is.

During the walk-through, the help-desk want to see the same web-pages the
client sees.  However, they have to login as a seperate session, so they
have to fill out their own copy of the web forms and hope that the customer
is following their instructions properly.

Of course, I'm using WAA for my web-apps, so things are a little more
complicated in this regard for me than for Xb2.NET users (actually, a LOT
more complicated as far as this is concerned).  However, I think I've
figured out a way to allow the help-desk to see the exact same pages the
customer is submitting.

The scenario is slightly different for WAA and Xb2.NET because with WAA you
cannot edit the engine code, only the packages.  With Xb2.NET you can of
course edit everything.

Basically, you need to be able to notify WAA/Xb2.NET about which requests
should be monitored.  With Xb2.NET you can simply connect to the server and
send a command to enable/disable watching with some parameters to help
identify which requests to monitor (based on client-id, ip-address etc). 

A seperate application should send ths request to the server, and
preferably also be able to record which connections are active over a
period.  A conduit is opened between the server and the application during
watching periods, which is globally accessible within the server.

When the server receives a request from a watched client, it copies any
returned resources back to the application through the conduit. This
secondary application is middle-ware (we'll call it MW for short).

A third application (let us call it MONITOR) connects to MW and requests a
watch (or requests a list of active connections).  MONITOR establishes two
channels with MW - one for issuing commands, one for receiving responses.

Once MONITOR has established a watch session, it waits for updates.  When
the server fulfills a request, it sends it to MW, which then forwards it to
MONITOR, which can then display it in an XbpDialog with IE ActiveX control.

The middle-ware layer is required only so that a single 'watch' can be
shared (broadcast) amongst several MONITORs, otherwise it can be
incorporated straight into MONITOR.

Embedding this technology in WAA is a little difficult to say the least
because of the architecture and because you cannot build the required
routines straight into WAA1SRV.EXE, which is the best place for it.  With
Xb2.NET, things get much simpler.

I've written this message because the task of writing this capability is
very low priority for us, so I don't know when I can get around to starting
work on it, and how much time I'll be able to spend on it once work has
started.  Having worked out the fundamentals, I thought I'd share in case
it proves useful to anyone else.

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Programmers don't get sniffles, they get a CODE.

Phil,
 
> Of course, I'm using WAA for my web-apps, so things are a little more
> complicated in this regard for me than for Xb2.NET users (actually, a LOT
> more complicated as far as this is concerned).  However, I think I've
> figured out a way to allow the help-desk to see the exact same pages the
> customer is submitting.

when the helpdesk finds a way to obtain the very same cookie your
customer has obtained from WAA, the helpdesk can logon to the very same
session and see the very same data like the customer.

Just a thought,
--
Hannes

Hannes,

> when the helpdesk finds a way to obtain the very same cookie your
> customer has obtained from WAA, the helpdesk can logon to the very same
> session and see the very same data like the customer.

It's a cookie free system.  Also, just because you have the same cookie as
the customer does NOT mean you can see each page as they download them.
It only enables you to spoof them, which we can do already through a master
password system.  The difference here is that whilst we can spoof the
client and gain access to their data as they see it, the system knows who
we really are.  Using the mirroring system above, we can monitor the
customer's progress through our system, and advise them over the phone
about what data to enter and which buttons to push (we can't see the data
being entered, only submitted).  Also, this system allows me to re-write
the pages as they go to the help-desk, allowing the HD user to do anything
on the page except submit data - a very important safety tool.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Hey Pee Wee, Button your fly!

Phil,

> It's a cookie free system.  Also, just because you have the same cookie as
> the customer does NOT mean you can see each page as they download them.
> It only enables you to spoof them, which we can do already through a master
> password system.  The difference here is that whilst we can spoof the
> client and gain access to their data as they see it, the system knows who
> we really are.  Using the mirroring system above, we can monitor the
> customer's progress through our system, and advise them over the phone
> about what data to enter and which buttons to push (we can't see the data
> being entered, only submitted).  Also, this system allows me to re-write
> the pages as they go to the help-desk, allowing the HD user to do anything
> on the page except submit data - a very important safety tool.

its a quite impressing system you describe.

If I ever have a problem on the Web, I know whom to ask 

Regards,
--
Hannes

Hannes,

>> It's a cookie free system.  Also, just because you have the same cookie as
>> the customer does NOT mean you can see each page as they download them.
>> It only enables you to spoof them, which we can do already through a master
>> password system.  The difference here is that whilst we can spoof the
>> client and gain access to their data as they see it, the system knows who
>> we really are.  Using the mirroring system above, we can monitor the
>> customer's progress through our system, and advise them over the phone
>> about what data to enter and which buttons to push (we can't see the data
>> being entered, only submitted).  Also, this system allows me to re-write
>> the pages as they go to the help-desk, allowing the HD user to do anything
>> on the page except submit data - a very important safety tool.
> 
> its a quite impressing system you describe.
> 
> If I ever have a problem on the Web, I know whom to ask 

Well, it's all based around WAA and HRF (BTW,who wrote HRF?).  Writing
XbHAL was one of the most important things I ever did, because it allowed
me to write HTML pages simply and easily and without having to keep track
of the current HRF object. In my mind, HRF is the single-most important
library ever to come out of the Alaska stable.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

"Pieces of Seven! Pieces of Seven! SQUAWK!" (Parroty error)

Hannes Ziegler <Hannes_Ziegler@Compuserve.com> wrote in 
news:42684F07.FB6BF4F@Compuserve.com:

> when the helpdesk finds a way to obtain the very same cookie your
> customer has obtained from WAA, the helpdesk can logon to the very same
> session and see the very same data like the customer.

I don't thinks so. The simple act of logging on and doing something will 
change the session data. And since you have the same cookie, you will be 
changing the customers session data!

Best regards,
Boris Borzic

http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

Boris,

> I don't thinks so. The simple act of logging on and doing something will
> change the session data. And since you have the same cookie, you will be
> changing the customers session data!

When I know a session ID, I don't have to logon, I can enter a session.

FWIW, I was (implicitly) referring to WAA cookies identifying a WAA
session. They serve as session ID and are stored for 60 days on the
server unless a WAA session is closed on the
client side. That means, if someone could get access to the WAA cookie,
it is possible to get WAA session data. I.e. when the helpdesk knows the
WAA cookie identifying the customer's session, the helpdesk can read
customer's session data, immediately after submit.

Of course, that's not possible with Phil's cookie-free system.
(BTW, I'm not quite sure if Phil's system is really cookie-free. WAA
sessions rely on cookies sent by WAA)

Regards,
--
Hannes

Hannes Ziegler <Hannes_Ziegler@Compuserve.com> wrote in 
news:4269A88A.444486EE@Compuserve.com:

> when the helpdesk knows the
> WAA cookie identifying the customer's session, the helpdesk can read
> customer's session data, immediately after submit.

I think Phil want's something more ambitious. That is to see a copy of the 
exact screen that the customer is looking at and not just data that may be 
stored in the server's session cache.

Best regards,
Boris Borzic

http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

Boris,

> I think Phil want's something more ambitious. That is to see a copy of the
> exact screen that the customer is looking at and not just data that may be
> stored in the server's session cache.

well, this is really ambitious 
I doubt if that can be achieved unless a VPN is used ...
 
Best regards,
--
Hannes

Hannes,

> I doubt if that can be achieved unless a VPN is used ...

I guess you mean Remote Desktop or pcAnywhere. 
VPN would be of no use here.

The closest thing to what Phil means I've seen it utilized by
Teleroute. (www.teleroute.com) When calling the helpdesk 
they ask you to go to a special page where you can download
an ocx, subsequently you have to repeat your actions, and then
 the helpdesk can monitor.

The helpdesk told me the stuff came from somewhere in France.

As a client you must have your security settings set between low 
and off.

HTH, & Regards,
Frans Vermeulen

Frans Vermeulen schrieb:
> Hannes,
> 
>> I doubt if that can be achieved unless a VPN is used ...
> 
> 
> I guess you mean Remote Desktop or pcAnywhere. VPN would be of no use here.
> 
> The closest thing to what Phil means I've seen it utilized by
> Teleroute. (www.teleroute.com) When calling the helpdesk they ask you to 
> go to a special page where you can download
> an ocx, subsequently you have to repeat your actions, and then
> the helpdesk can monitor.
> 
> The helpdesk told me the stuff came from somewhere in France.
> 
> As a client you must have your security settings set between low and off.
> 
> HTH, & Regards,
> Frans Vermeulen
>
Frans, Phil, Hannes,

we use inquiero. No problems with firewalls, viren scanner.
It is fast, no need to install a client (VPN). A must for
our support.

take a look at their site:

http://www.inquiero.com/

Regards,
Klaus Overhage

Frans Vermeulen schrieb:
> Hannes,
> 
>> I doubt if that can be achieved unless a VPN is used ...
> 
> 
> I guess you mean Remote Desktop or pcAnywhere. VPN would be of no use here.
> 
> The closest thing to what Phil means I've seen it utilized by
> Teleroute. (www.teleroute.com) When calling the helpdesk they ask you to 
> go to a special page where you can download
> an ocx, subsequently you have to repeat your actions, and then
> the helpdesk can monitor.
> 
> The helpdesk told me the stuff came from somewhere in France.
> 
> As a client you must have your security settings set between low and off.
> 
> HTH, & Regards,
> Frans Vermeulen
> 
also we do traning and product demonstration with this,
the user need only a headset or a speaker and a micro.

Klaus

Frans & Klaus,

> The helpdesk told me the stuff came from somewhere in France.
> 
> As a client you must have your security settings set between low
> and off.

Thanks for pointing me at two interesting products. I'll have a look at
these.

Regards,
--
Hannes

Hannes,

>> I think Phil want's something more ambitious. That is to see a copy of the
>> exact screen that the customer is looking at and not just data that may be
>> stored in the server's session cache.
> 
> well, this is really ambitious 
> I doubt if that can be achieved unless a VPN is used ...

Not at all - it's actually quite simple in principle.

Before you return from your WAA_FORM function, you can do stuff with the
data written to oHtml.  Using XbHAL you can call the MyDoc():asString(),
and you can do a similar thing with Xb2.NET oOut object.

The architecture of an XbHAL session is as follows:

Form-func prepares XbHAL objects and stacks then calls the user-func which
generates the page.  When the user func returns, the XbHAL objects and
stacks are destroyed and the html page is written to the oHtml/oOut object.

.e.g.:

Function MyFormFunc( oHtml, oContext )
   if SessionBegin( oHtml, oContext )
      _MyFormFunc( oHtml, oContext )
   endif
   SessionEnd( oHtml, oContext )
   return TRUE

Function _MyFormFunc( oHtml, oContext )
    generate page...
   return TRUE

In the SessionEnd() function, the created page can be sent through one
means or another to an application that is has an IPC connection to WAA.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

A Qmodem is a happy modem!

Hannes,

> Of course, that's not possible with Phil's cookie-free system.
> (BTW, I'm not quite sure if Phil's system is really cookie-free. WAA
> sessions rely on cookies sent by WAA)

It is cookie-free.  It never used to be, although we never used WAA
sessions anyway.  Last year though, it became necessary for the help-desk
to open two browser windows, and to login as different people in each
window.  Using cookies this just wasn't possible - the cookies would
overwrite each other, so I changed the system to work without cookies.

Using XbHAL2 this is the easiest thing in the world - simple create an
hidden input variable and 'announce' that variable to the XbHAL system.
Whenever it creates a new form, it looks for any announced variables and
copies them to the new form.

  in SessionBegin()
 oMyDoc:formCallback := {|| AdditionalHiddenVars() }


Function AdditionalHiddenVars()
   local cID := httpDefVar(cid,'')

   if !Empty(cID)
      HIDE cid=(cID)
   endif
   return Nil

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

According to my calculations the problem doesn't exist.

Phil Ide <phil@idep.org.uk> wrote in news:4d1elpl4z18d.dlg@idep.org.uk:

> Last year though, it became necessary for the help-desk
> to open two browser windows, and to login as different people in each
> window.  Using cookies this just wasn't possible - the cookies would
> overwrite each other, so I changed the system to work without cookies.

"Session" cookies should not overwrite each other.

Best regards,
Boris Borzic

http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

Boris,

>> Last year though, it became necessary for the help-desk
>> to open two browser windows, and to login as different people in each
>> window.  Using cookies this just wasn't possible - the cookies would
>> overwrite each other, so I changed the system to work without cookies.
> 
> "Session" cookies should not overwrite each other.

Hehe, we're getting a bit circular here.  We haven't used cookies since
last year, and prior to that only for keeping track of who the current user
is. I've never used 'context sessions' in the apps at the office simply
because we don't need them.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Infinity is one lawyer waiting for another.