Opened on 11/02/2014 at 12:27:31 PM

Last modified on 11/05/2014 at 03:01:26 PM

#1519 new defect

ABP doesn't properly handle the multi user situation

Reported by: Semisonic Assignee:
Priority: P3 Milestone:
Module: Adblock-Plus-for-Android Keywords:
Cc: Blocked By:
Blocking: Platform: Android
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):

Description

It's kinda weird this issue's not yet reported, especially since it's more than a year old: https://adblockplus.org/forum/viewtopic.php?t=16897

Environment

I have a tablet running Android 4.4.2 and ABP 1.2.1 installed. But that doesn't really matter. What matters is that the tablet is configured to have multiple users.

How to reproduce

  1. Set up User1 and User2 accounts on Android.
  2. Install ABP for User1. It will launch itself as a localhost proxy at port 2020 (it was that way in my case). Manage the WiFi settings so it uses this proxy. Note that WiFi settings are shared between all the users.
  3. Now reboot the device and log in using User2. Now every time he's attempting to use the internet, the "Proxy refuses connection" error will appear. It's okay, because ABP was installed for User1, he's not logged in so ABP isn't really running.
  4. Install ABP for User2. Now it will set up itself as a localhost:2020 proxy. Everything seems to be fine, but...
  5. Log into User1. His instance of ABP launches during the log-in process and is frustrated to find that localhost:2020 is already occupied (by the User2's ABP running in background). So it re-registers itself to listen the port 3030 and then tells you to alter the WiFi settings so the traffic starts flowing through it. Yet everything's working properly, since the localhost:2020 listener is actually an ABP proxy launched by User2 and it's working now.
  6. Now reboot the device and log into User1. The fun begins here since the WiFi connection is set to use a port 2020 proxy, and ABP is already switched to listening the port 3030. Thus you have the "proxy refusing connection" situation again, and this time there's no good way out of it.

Observed behaviour

Pretty much explained in the previous section.

Expected behaviour

The proper way of dealing with the situation is to honor the WiFi proxy settings as the most stable and relevant and worth following. So, if ABP launches and finds out that the port it's supposed to listen on is already occupied, it should adhere to the following pattern:

  1. If possible, check whether the current listener is another instance of ABP. In that case, just report "Everything's okay" to the user.
  2. If there's no way to check if the current port listener is another instance of ABP or a proxy at all, simply inform the user about it and let him decide what to do next. The options might be "The current listener is indeed ABP, act as if everything's okay", "Let's assign you a different port number and alter the WiFi settings" and "It may not be ABP, but let's not change anything, shall we. Simply give me a persistent notification about this situation".

The proposed way seems perfect to me, because it would allow ABP to gracefully handle all the possible situations without causing trouble and starting a settings war between multiple users.

Attachments (0)

Change History (3)

comment:1 Changed on 11/02/2014 at 04:44:21 PM by mapx

  • Component changed from Unknown to Adblock-Plus-for-Android

comment:2 Changed on 11/05/2014 at 03:01:16 PM by rjeschke

Thanks, never though about this. Yes, solution 1 (checking for already running ABP would be the best solution here (and is also possible) ).

comment:3 Changed on 11/05/2014 at 03:01:26 PM by rjeschke

  • Priority changed from Unknown to P3
  • Ready set

Add Comment

Modify Ticket

Change Properties
Action
as new .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from (none).
Next status will be 'reviewing'.
 
Note: See TracTickets for help on using tickets.