Co-browsing doesn't request user permission

GrumpyUnixAdmin · 2016-03-15 21:21:30

Hi,

I see from previous posts on here that co-browsing is a rather complex subject but I have managed to get a way into the issue and hope that the cause is something minor.

I'm using 2.44 and chats work fine but screen co-browsing and screen shots don't work as the user isn't prompted for permission for the screen sharing to start. I have set up node.js and can see that it's working by running it manually in debug mode. When the chat admin requests co-browsing session (by clicking on the blue eye icon) the node server sees a response similar to:

joinadmin:25_ed60435104df6105c765e289c7eff0ea0fe7b21a

and the client responds with a GET request (which succeeds) to http://<host>/chat/index.php/chat/syncuser/25/89/ed60435104df6105c765e289c7eff0ea0fe7b21a?_=1458063092127 with a body similar to:

{"error":"false","op":["lhc_cobrowse:25_ed60435104df6105c765e289c7eff0ea0fe7b21a"],"uw":"true","msop":0,"cs":"f","ott":"","message_id":0,"result":"false","status":"true","blocked":"false"}

but nothing is displayed on the client. When "Show my mouse position to visitor" is checked, I can see the mouse data being streamed to the node.js server but the user's screen isn't displayed and the chat admin's screen frame stays displaying "Click blue eye at the top to request screen share..."

Likewise, snapshot requests get a response like this:

{"error":"false","op":["lhc_screenshot"],"uw":"true","msop":0,"cs":"f","ott":"","message_id":0,"result":"false","status":"true","blocked":"false"}

but then fails in the chat admin's browser.

Neither client display any errors in their consoles (indicating a missing file or bad request) and I'm running out of ideas. Are there any extra logging options I can set of logs I should be looking in? I have also tried setting "Do not ask permission for users to see their screen" but that hasn't made any difference.

Does anyone have any ideas? Thanks.

Last edited by GrumpyUnixAdmin (2016-03-15 21:24:03)

PeopleInside · 2016-03-16 06:32:28

Hi, thank you for your topic in the Live Helper Forum.
I AM sorry but I can't help you with that.
Maybe only chat owner but seems him is very busy... so sorry if you will not have a reply here about this issue.

zet · 2016-03-16 08:17:14

Just an idea (I'm not using this feature):

Are you sure your firewall isn't blocking any relevant port?

GrumpyUnixAdmin · 2016-03-16 20:32:07

Well, I thought this may be a slightly complex issue :-)

The clients show that their requests are working fine (HTTP 200 responses) which would show that it isn't a firewall issue and I've tested it with two devices on the same subnet and I get the same issue. I've also tried different browsers so I'm wondering if the issue could be with JavaScript. The trouble is that I don't really understand the communications flow between the clients (the docs are a little thin) which makes debugging it a little challenging. One thing I have also thought of is the possibility that there may be an issue with the iframe which is supposed to display the remote screen on the chat admin's terminal but I can't work out how that is connected to the approval process on the client's screen and why that is not showing.

GrumpyUnixAdmin · 2016-03-16 22:17:29

I've been through the process with a fine toothed comb again and it seems that the clients don't throw any errors at all. I have also checked the co-browsing without the node.js support and it seems that problem is still there which would indicate that it's an AJAX/JS issue and not a node.js problem.

Does anyone use co-browsing? I'd love to know which version you're running as I'm starting to wonder if it's a version issue.

PeopleInside · 2016-03-16 22:35:38

Have you tried to reproduce in the demo of live helper chat?

GrumpyUnixAdmin · 2016-03-17 10:44:29

Yes, and I've checked that the system I am working on has the same settings as the demo. The demo works but our system doesn't.

One thing I did notice is that our standard Apache XSS hardening was preventing some features (such as the Chrome app) but it doesn't seem to be connected to the co-browsing issue.

PeopleInside · 2016-03-17 11:00:48

HI GrumpyUnixAdmin,
so is not Live Helper Chat Issue.. is not a BUG... and don't know your system.
Sorry but in this case is hard help you with that. Maybe can be some wrong settings in Live Helper Chat? You should try to install again a new clear Live Helper Chat and try co browsing with default settings.

Maybe your custom settings of Co-Browsing make the issue present.

GrumpyUnixAdmin · 2016-03-17 11:46:25

Actually, I have tried the demo site again this morning and it shows the same error as our site. So it looks like it is a code related issue (perhaps the demo site has the same issue as the one I'm testing?).

Interestingly I'm also seeing:

"GET /chat/socket.io/?EIO=3&transport=polling&t=1458212322487-14 HTTP/1.1" 404

from the admin chat screen so perhaps it is a socket.io issue? Perhaps someone with working co-browsing can share a line from their apache access log where this URI works?

zet · 2016-03-17 11:48:53

I just gave it a try here on my local testing instance ...

SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux
Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u2
LivehelperChat 2.40v without node.js

and co-browsing is working out of the box.

I noticed that after screen sharing permission is granted, some extra javascript is injected into the head section like
<script type="text/javascript" src="//..../cache/compiledtemplates/3ed2b182994d2c21ab95a6d5f4533aaf.js"></script>

Maybe your "hardened" apache is preventing things like that?, don't know ...

As for more debugging: perhaps it's worth to add some php error_logs to
design\defaulttheme\tpl\lhchat\getstatus.tpl.php below function startCoBrowse()
in order to verífy whether

s.setAttribute('src','<?php echo erLhcoreClassModelChatConfig::fetch('explicit_http_mode')->current_value?>//<?php echo $_SERVER['HTTP_HOST']?><?php echo erLhcoreClassDesign::designJS('js/cobrowse/compiled/cobrowse.visitor.min.js');?>');

is issued at all ?
(cache/compiledtemplates/3ed2b182994d2c21ab95a6d5f4533aaf.js in fact is the compiled version of cobrowse.visitor.min.js)

GrumpyUnixAdmin · 2016-03-17 16:41:25

Thanks, Zet, that's very helpful. Did you do the install into the docroot or a subdirectory?

I've backed out the hardening changes so I've managed to eliminate them (they're there to prevent the most common types of XSS attacks and data leakage) but I'll try a fresh install of 2.40 and see if that is the issue.

yargosaurus · 2016-03-18 20:35:25

Howdy all.

I'm working on a fresh install as well and am running into the same problem.

I have tested downgrading from 2.44 incrementally to 2.40 and have found no difference.

I've tested browsers, with/without addons loaded. No difference.

Even different OS's and browsers. Linux/Mac Firefox - Safari

I don't have any Windows machines available to try with.

I did test it on the demo site and it works exactly the same for me there as well. I click on the blue eye and nothing happens.

The only thing that I have in common to both my site and the demo site is my firewall. I have checked the logs and I show nothing blocking any of this traffic. This isn't a COTS unit, its logging is verbose. I'm rather baffled...

I want to lean towards code, but if it's working on zets rig with 2.40 and I tested 2.40 with a default, fresh install as zet stated, it shouldn't be the code. It should be the environment. But if it works on the demo site the same as it works on my site (as in not working), it shouldn't be the environment any longer, as I can't imagine any reason the demo site wouldn't have worked...unless it just didn't/doesn't.

Should anyone figure out what the fix is, please post it. I've just figured out a lot of what the fix isn't.

PeopleInside · 2016-03-18 20:37:05

If you think there are a BUG please report here: https://github.com/LiveHelperChat/liveh … issues/new and idicate also the link to this topic, thank you.

zet · 2016-03-19 09:41:21

Marco,
excuse me, but I don't think this forum was intentionally meant to be a contest of who's the one with the maximum number of postings. Yes, we could file a bug report. But up to now all we know is: sometimes it works, sometimes it fails. In other words: We're still in the very beginning of sorting out conditions, knowing hardly anything at all. And posting a report based on a 'knowledge' like that is nothing but a waste of time and useless. As your comment above. You're spending a lot of time trying to help - that's great, but I don't see no sense in all those postings where you can't.

Okay,back to GrumpyUnixAdmin's question: My test server here at home is running 2.40v from a subdirectory of the docroot. But I don't think this is making a difference. Because, yesterday I gave it another try on our live website outside:
Same 2.40v, but installed directly into docroot, set up to run without index.php, and a different php (5.6). My connection is made by a FritzBox (no special settings) and I was trying Chrome/Firefox on Win10, one time being the operator on chrome, the other time being the operator on Firefox.

Same result: co-browing is running flawlessly.

So what's different on my side? Perhaps the simple client side test page? Actually, we're not using (nor attempting to make use of) Livehelpers chat functionality. And that's why I put the widget code on an extra page with just a minimal head and body section and no other javascript.

Thus, in case your pages include additional scripts there may be interferences? ... sorry, but no other idea at the moment.

PeopleInside · 2016-03-19 10:11:11

zet wrote:

Marco,
excuse me, but I don't think this forum was intentionally meant to be a contest of who's the one with the maximum number of postings. Yes, we could file a bug report. But up to now all we know is: sometimes it works, sometimes it fails. In other words: We're still in the very beginning of sorting out conditions, knowing hardly anything at all. And posting a report based on a 'knowledge' like that is nothing but a waste of time and useless. As your comment above. You're spending a lot of time trying to help - that's great, but I don't see no sense in all those postings where you can't.

Hi zet,
you are a new member on the Live Helper Chat Forum.
Before your arrive many topic was opened from user and still be without anyone who make some replies or help.

I suggested to open a BUG because is the only way to find a solution at the moment at the issue BUT if you are able to test better and again and discuss here so have more info and open a complete report will be better.

Have a great time and good luck with this issue :-) I AM sorry but I AM not using co-browser at the moment and I don't have more info can help you about that.
You can continue to discuss here.

Last edited by PeopleInside (2016-03-19 10:12:05)

GrumpyUnixAdmin · 2016-03-19 23:34:12

Hi yargosaurus. I'm sorry to hear you're having some issues but it's nice to know I'm not going mad!

It's very strange that the issue seems to affect the demo and our installations but I suspect that the issue isn't the firewall as I've been testing my local installation from a workstation on the same LAN segment as the server which would rule that out. I did try browsing the demo site again with an "in private" session as this doesn't use cached data and it worked so I suspect that the issue may be cache related (for the demo site at least). Perhaps the issue is related to the shared socket.io library?

Unfortunately, trying a non-cached version of local site didn't fix the issue.

I'm running CentOS 7.2 which has php 5.4, selinux and iptables disabled. LHC is installed in a subdirectory.

Last edited by GrumpyUnixAdmin (2016-03-19 23:36:04)

yargosaurus · 2016-03-20 18:11:18

Hello there, GrumpyUnixAdmin.

Yeah, that was why I posted it. I was afraid that if I didn't, you'd figure it out, move on and I'd be the only other person sitting around scratching their head going nuts.

I have really wondered hard about the socket.io deal. Without getting any good errors, I'm really not sure how to trouble shoot it. The only time I've actually gotten an error was when modsecurity pitched a fit about an offsite file, when i was testing to see if I screwed it up pulling it onsite. I even tried the updated 1.4.5 version. Didn't seem to make any difference.

Part of me wonders if I need to get a Windows machine and plug it directly into the cable modem and see what happens. I'd probably explode into confetti if it worked. Heh.

I'm leaning more towards this is going to be an "id ten T" error on our behalves, but I don't see what the problem is. It probably is not the code, not the environment per-se, but some stupid ass little box we did/didn't check. Now where, that box is, is the million dollar question.

Other than having what sounds like security minded installations, we're using pretty different rigs. But even when I turn my security off in the test lab for that piece during testing, I get the same results.

Which walks me back into a circle of, the demo site does it too. Sorry to bother you with this, but, zet, if you go to the demo site and try, does it work for you? I'm hoping it won't, but suspect it will.

I actually uninstalled no-script during testing, instead of relying on running it in safemode without plugins, but what if its something in our browsers that is causing this.

zet · 2016-03-20 22:22:37

Part of me wonders if I need to get a Windows machine ....

I'm afraid you have to, since the majority IS using windows. Sorry. smile

Anyway, and in order to give some feedback I just checked LiveHelper's demo site, this time with
- Firefox 34 on Lubuntu (kernel 3.16)
- Chrome on a Nexus 7 android tablet

No problems. Request for permission alert appeared correctly in both cases, and even on Android moving my finger across the tablet made the cursor move in the operator window. I'm more and more convinced your client pages must be some way special...

Last edited by zet (2016-03-20 22:31:47)

GrumpyUnixAdmin · 2016-03-21 17:31:59

I have tested Edge 25.10586 and Chrome 49.0.2623.87 both on Windows 10 so I don't think it's a platform issue. smile

It probably is not the code, not the environment per-se, but some stupid ass little box we did/didn't check. Now where, that box is, is the million dollar question.

I'm starting to think the same thing too. I found that the socket.io path, optional setting needed to be set as I had installed LHC in a subdirectory and, for some reason, the code wasn't picking it up correctly. I'll get it raised as a bug as detecting if the code is installed in a subdirectory is quite simple.

Last edited by GrumpyUnixAdmin (2016-03-21 17:38:06)

GrumpyUnixAdmin · 2016-03-21 20:53:23

I've just tested a fresh install into the docroot of a newly installed CentOS 7 machine (with SELinux and firewall disabled) and it also doesn't work hmm

I have also tried disabling the Windows firewall with no joy. I'll try another OS and see if it's a CentOS specific problem but I'm starting to wonder if it couldn't be an Apache settings issue so I'll look at that when I get a moment.

Last edited by GrumpyUnixAdmin (2016-03-21 20:59:03)

GrumpyUnixAdmin · 2016-03-22 11:56:41

I've just seen this on the LHC commercial offerings page:

Offer just for snapshot where configuration will be done purely by you is 50$
Image is using Centos 7 as OS

so that rules out it being a CentOS issue...

GrumpyUnixAdmin · 2016-03-22 14:50:06

And I've just spun up a Digital Ocean CentOS 7 machine and co-browsing doesn't work on there either (LHC 2.44).

zet · 2016-03-23 14:55:16

Grumpy,

I see you're still investigating the server side ... Just for your convenience, this is the client html I tested co-browsing successfully with
- Firefox, Chrome and Edge on Win10
- Firefox and Chrome on Ubuntu
- Chrome on Nexus 7 tablet
- using
1. livehelperchat demo server
2. my own server running 2.40v (of course then with adapted url in javascript)

<!doctype html>
<html lang="de">
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
</head>
<body class="zet-body">
<div style="height:400px">
testpage
</div>


<script type="text/javascript">
var LHCChatOptions = {};
LHCChatOptions.opt = {widget_height:340,widget_width:300,popup_height:520,popup_width:500};
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
var referrer = (document.referrer) ? encodeURIComponent(document.referrer.substr(document.referrer.indexOf('://')+1)) : '';
var location  = (document.location) ? encodeURIComponent(window.location.href.substring(window.location.protocol.length)) : '';
po.src = '//demo.livehelperchat.com/chat/getstatus/(click)/internal/(position)/bottom_right/(ma)/br/(top)/350/(units)/pixels/(leaveamessage)/true?r='+referrer+'&l='+location;
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
</script>
</body>
</html>

Last edited by zet (2016-03-23 14:56:05)

yargosaurus · 2016-03-24 01:34:57

GrumpyUnixAdmin wrote:

I found that the socket.io path, optional setting needed to be set as I had installed LHC in a subdirectory and, for some reason, the code wasn't picking it up correctly. I'll get it raised as a bug as detecting if the code is installed in a subdirectory is quite simple.

Did you require that with the url loaded also? I had removed the URL and was only trying to use a local copy on my box.

But it didn't seem to matter either way for me. One, the other, or both.

yargosaurus · 2016-03-24 01:39:31

zet wrote:

1. livehelperchat demo server
2. my own server running 2.40v (of course then with adapted url in javascript)

<!doctype html>
<html lang="de">
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
</head>
<body class="zet-body">
<div style="height:400px">
testpage
</div>


<script type="text/javascript">
var LHCChatOptions = {};
LHCChatOptions.opt = {widget_height:340,widget_width:300,popup_height:520,popup_width:500};
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
var referrer = (document.referrer) ? encodeURIComponent(document.referrer.substr(document.referrer.indexOf('://')+1)) : '';
var location  = (document.location) ? encodeURIComponent(window.location.href.substring(window.location.protocol.length)) : '';
po.src = '//demo.livehelperchat.com/chat/getstatus/(click)/internal/(position)/bottom_right/(ma)/br/(top)/350/(units)/pixels/(leaveamessage)/true?r='+referrer+'&l='+location;
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
</script>
</body>
</html>

Are you putting this into the index.php file? I have an idea of what it is doing, but I don't quite understand where this would go. Once I understand where it goes, I'll figure out what exactly is happening, and will then test it.

I suspect this line has something to do with it:
po.src = '//demo.livehelperchat.com/chat/getstatus/(click)/internal/(position)/bottom_right/(ma)/br/(top)/350/(units)/pixels/(leaveamessage)/true?r='+referrer+'&l='+location;

As it is pulling in data from offsite.

Tomorrow I'll try wiring past the FW and seeing what happens.

Announcement

#1 2016-03-15 21:21:30

Co-browsing doesn't request user permission

#2 2016-03-16 06:32:28

Re: Co-browsing doesn't request user permission

#3 2016-03-16 08:17:14

Re: Co-browsing doesn't request user permission

#4 2016-03-16 20:32:07

Re: Co-browsing doesn't request user permission

#5 2016-03-16 22:17:29

Re: Co-browsing doesn't request user permission

#6 2016-03-16 22:35:38

Re: Co-browsing doesn't request user permission

#7 2016-03-17 10:44:29

Re: Co-browsing doesn't request user permission

#8 2016-03-17 11:00:48

Re: Co-browsing doesn't request user permission

#9 2016-03-17 11:46:25

Re: Co-browsing doesn't request user permission

#10 2016-03-17 11:48:53

Re: Co-browsing doesn't request user permission

#11 2016-03-17 16:41:25

Re: Co-browsing doesn't request user permission

#12 2016-03-18 20:35:25

Re: Co-browsing doesn't request user permission

#13 2016-03-18 20:37:05

Re: Co-browsing doesn't request user permission

#14 2016-03-19 09:41:21

Re: Co-browsing doesn't request user permission

#15 2016-03-19 10:11:11

Re: Co-browsing doesn't request user permission

#16 2016-03-19 23:34:12

Re: Co-browsing doesn't request user permission

#17 2016-03-20 18:11:18

Re: Co-browsing doesn't request user permission

#18 2016-03-20 22:22:37

Re: Co-browsing doesn't request user permission

#19 2016-03-21 17:31:59

Re: Co-browsing doesn't request user permission

#20 2016-03-21 20:53:23

Re: Co-browsing doesn't request user permission

#21 2016-03-22 11:56:41

Re: Co-browsing doesn't request user permission

#22 2016-03-22 14:50:06

Re: Co-browsing doesn't request user permission

#23 2016-03-23 14:55:16

Re: Co-browsing doesn't request user permission

#24 2016-03-24 01:34:57

Re: Co-browsing doesn't request user permission

#25 2016-03-24 01:39:31

Re: Co-browsing doesn't request user permission

Board footer