Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xbrowsersync beta 1.4.1beta2 fails to connect #21

Open
swestlake opened this issue Jan 8, 2019 · 3 comments

Comments

@swestlake
Copy link

commented Jan 8, 2019

I began trying xbrowsersync beta 1.4.1beta2 since I could not manage to get the previous release to connect successfully to a private api server..

I can run tcpdump on the server side and attempts are made to a custom port 5600. so I know by using http://mycustom.com:5600/ , the app is trying to connect but it just appears to do syn/ack back and forth without going much beyond "Hello Client"..

I ran the integrationtest on the server end and all passes...

I have the server running,
{"name":"xBrowserSync_api","hostname":"machinexyz","pid":21673,"level":30,"msg":"Service started on 9.9.9.9:5600","time":"2019-01-08T05:10:09.064Z","v":0}
^ I can do ctl-c at any time to shutdown the service so I know the server is running..

Browser: chromium 71 (in developer mode, and loaded the extracted extension)
OS: Linux Debian (stretch -- latest release)

I am using a 32-bit Linux system, and I found out that nodejs only goes up to version 8, as the nodejs team has dropped support for 32-bit starting from version 10.

What version are you using for mongodb and nodejs?, then I can try duplicate the setup a little more and see then what works and what doesnt....

(fwiw I noticed a benign typo @ "If set to true no clients will be able to connect to this service." -- https://github.com/xbrowsersync/api)

thanks

@nero120 nero120 added the question label Jan 8, 2019

@nero120

This comment has been minimized.

Copy link
Member

commented Jan 8, 2019

I don't have the capacity to test with your configuration unfortunately. The API always supports the current LTS versions of node and mongodb (10 and 4 respectively), but should work fine with node 8 and mongojs 3 as far as I'm aware (it wasn't that long ago I was using those versions). However, I've never tested with a 32-bit setup so that could be an issue.

Couple of things to check (on the same server you are running the service):

I would have suggested using the API Docker image instead but it appears Docker doesn't support 32-bit hosts.

(fwiw I noticed a benign typo @ "If set to true no clients will be able to connect to this service." -- https://github.com/xbrowsersync/api)

Thanks! Corrected.

@swestlake

This comment has been minimized.

Copy link
Author

commented Jan 8, 2019

There's an oddity when https: is first tried, http: kept failing .. The fix here (chromium) was to clear all cache and then it worked to pass the "Hello Client" application handshake. http://mycustom.com:5600/info and http://9.9.9.9:5600/info work in the web instances for chrome,chromium and firefox ... It was only chromium which needed a cache cleaning because I initally attempted to use https: for 1 second, and immediately after http: would never work...

Testing a sync between Chrome and Chromium(both using 1.4.1beta2)... I think it synced all the bookmarks, as I can merely type in 'z' or 'a' and select all bookmarks (chrome/chromium's internal search tool in chrome://bookmarks/) and I get the same amount of selected bookmarks..

I tried using Firefox with 1.4.0 and it synced only 97 items, maybe it's because you haven't yet released a later plugin for it..

I noticed this in my nodejs debug output,
"(node:28830) DeprecationWarning: collection.findAndModify is deprecated. Use findOneAndUpdate, findOneAndReplace or findOneAndDelete instead."

I'm not sure what I tried to cause this, either it was chrome or chromium that did and they're both using 1.4.1beta2

I got https: working for both chrome and chromium, but I still get that debug output. I am using a letsencrypt signed certificate, but I'm keeping traffic on my local lan atm. It works great, I can see proper information regarding https:mycustom.com:5600/info

suggestion: users should be able to have access to a 'manual sync' so they can quickly test their setup rather than having to wait 15 minutes for the auto-sync..

Very important:

You should tell users that there is an "automatic deletion" of their bookmarks with your public server after some time of inactivity. There may be cases where users may have forgotten something when doing an android upgrade as people tend to be pre-occupied with their daily affairs... or at least to provided a warning via email that their bookmarks will become deleted... I haven't tried the public server so I wouldn't know better, but I was reading something about this in the FAQ and this is imho something which can catch innocent users by surprise to see all their bookmarks not recoverable.. even though it's good there's mention about creating backups...

So my obvious question here as I am new and reading the faq does not distinguish between the private and public servers, .. does this automatic deletion of inactivity also apply to the private server? it would be quite odd for it to be the case but I just want to make sure on this..

this project is very underrated and deserves to be more widely recognized

thanks for your dedicated efforts into this project, it looks worth my time and attention.. mind me giving a longer reply than usual, but I've been looking for something like for quite some time, so thanks again. (i think i will be adding something to help the project)

@nero120

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

Testing a sync between Chrome and Chromium(both using 1.4.1beta2)... I think it synced all the bookmarks, as I can merely type in 'z' or 'a' and select all bookmarks (chrome/chromium's internal search tool in chrome://bookmarks/) and I get the same amount of selected bookmarks..

It's much easier to open chrome://bookmarks if you're comparing rather than use the xBrowserSync interface. xBrowserSync creates local bookmarks so the bookmarks structure should be identical.

I tried using Firefox with 1.4.0 and it synced only 97 items, maybe it's because you haven't yet released a later plugin for it..

It should sync all of your bookmarks. Could be an error occurred, if you enable extension debugging in Firefox and enable Debug mode in xBrowserSync you should be able to see if any errors occurred.

I noticed this in my nodejs debug output,
"(node:28830) DeprecationWarning: collection.findAndModify is deprecated. Use findOneAndUpdate, findOneAndReplace or findOneAndDelete instead."

That's caused by one of the dependencies, shouldn't affect functionality.

suggestion: users should be able to have access to a 'manual sync' so they can quickly test their setup rather than having to wait 15 minutes for the auto-sync..

That's been requested as an app issue, will be delivered in the next version.

You should tell users that there is an "automatic deletion" of their bookmarks with your public server after some time of inactivity. There may be cases where users may have forgotten something when doing an android upgrade as people tend to be pre-occupied with their daily affairs... or at least to provided a warning via email that their bookmarks will become deleted... I haven't tried the public server so I wouldn't know better, but I was reading something about this in the FAQ and this is imho something which can catch innocent users by surprise to see all their bookmarks not recoverable.. even though it's good there's mention about creating backups...

I used to include some information about this in the app's help text, but it was removed due to space restrictions and the help text already being a bit long. The odd's of an active user's data being deleted are very small, every time their sync is accessed the date and time is recorded. This happens every 15 minutes whenever the browser is open and sync is enabled. So, for a user to have their data deleted they would have to have not opened their browser (with sync enabled), or opened the mobile app for more than three weeks - and to back that up I've not received any emails or issues from users regarding this as yet. I will take note though and think about how best to communicate this.

So my obvious question here as I am new and reading the faq does not distinguish between the private and public servers, .. does this automatic deletion of inactivity also apply to the private server? it would be quite odd for it to be the case but I just want to make sure on this..

There is no real distinction from the perspective of xBrowserSync. I suppose you could describe a "private" service as an xBrowserSync API that is solely for personal use, and a "public" service as one intended to be shared for other xBrowserSync users to sync to. Step 3.3 of the README describes configuring the db index that is responsible for the automatic deletion, it is entirely optional and up to the service admin whether they want to enable it.

this project is very underrated and deserves to be more widely recognized

thanks for your dedicated efforts into this project, it looks worth my time and attention.. mind me giving a longer reply than usual, but I've been looking for something like for quite some time, so thanks again. (i think i will be adding something to help the project)

That's much appreciated and is my pleasure, glad you're finding it useful! 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.