Admin device configuration not persisted?

[tamberg]

Working with the https://files.dyne.org/dowse/sdcard/devuan_dowse_raspi2.img.xz image setting an administrator on the Web UI does not seem to work. Entering a device name (set before via /things) in the "Your administrator device is not configured" text box looks fine, but afterwards said device does not have the admin role in /things and going back to / no device is set once again. Any ideas?

[freddbomba]

Is for DNS reasons, please try with a name that has only AZ/az and no symbols. I check, eventually we put in the interface some note about it.

fredd

On 6 Dec 2017, at 14:41, Thomas Amberg notifications@github.com wrote:

Working with the https://files.dyne.org/dowse/sdcard/devuan_dowse_raspi2.img.xz image setting an administrator on the Web UI does not seem to work. Entering a device name (set before via /things) in the "Your administrator device is not configured" text box looks fine, but afterwards said device does not have the admin role in /things and going back to / no device is set once again. Any ideas?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tamberg]

only AZ/az and no symbols

That's what I tried.

[parazyd]

Do you get redirected to the captive portal when this occurs?

[tamberg]

After entering a device name and clicking "Use this device as administrator" the page reloads and my device name is listed under "The admin devices configured are", but once I go to /things my device is still not an admin.

[parazyd]

That is indeed unusual.

If you open an SSH connection as the dowse user, get into the dowse shell and run redis-cli (also found in /usr/local/dowse/bin/redis-cli), you can issue a command keys *, see if your MAC address is there, and then `hgetall thing_{yourmac}' to see if you're indeed an admin in redis.

If not, you can try setting it manually with hset thing_{yourmac} 'isadmin' 'yes' However, if redis does say you are admin, then I suspect a HTML template bug. I can investigate further if you confirm this.

Thanks for attending these issues :)

[tamberg]

Ok, thanks.

$ ssh dowse@DOWSE_LOCAL_IP
% redis-cli
> hgetall thing_THING_MAC
 1) "isadmin"
 2) "no"
 3) "enable_to_browse"
 4) "no"
... 

and as you suggested, after

hset thing_THING_MAC 'isadmin' 'yes'

the same command

> hgetall thing_THING_MAC
 1) "isadmin"
 2) "yes"

And the Web UI shows the device as an admin in /things, but it still does not seem to have admin rights. Also, repeating the redis command above "isadmin" becomes "no" again.

[parazyd]

I think I've experienced this once, there is a reason I have in mind. It's how we handle new devices in the network and how they get put into redis. It's something I have to investigate more.

You should be able to mitigate this by using an older browser (possibly something even in command line like lynx). Then you would have to open the things page, enable yourself as admin directly in redis, refresh the web page and enable yourself to browse.

New browsers constantly try to HTTP GET/ remote files to see if they are in a captive network. In Dowse, we handle this by handling a 404 (because we don't serve that file), and we consider this a new thing, and add it to redis. That said, there might be some faulty logic in this piece of code. Try out some other browser that isn't smart enough to call remote sites and you should be able to proceed. If not, then you simply have to be fast enough in triggering the redis command to enable yourself and clicking enable to browse in the UI.

In the meantime I'll have a look at the 404 handling logic again.

[adam-burns]

Unfortunately, captive portal handling is distinct across OSes and browsers. From 2017, but this may help summarize.