Tib

From my point of view, I don't understand why :remove_secret is a variable. I prefer the way to define it via rest configuration scope but I agree that is purely...

I think that it is more logical if this config param is set under rest scope because it's REST/Web interface that display or not informations. This directive doesn't remove/rewirte anything...

Ok get it. :) When I reviewed the code of remove_secret, I thought these two toggles were OK to run together. Because they don't modify stuff on same level. In...

No problem. Actually, I don't have strict idea on this question. I think it could depends of use case as you said before. From my business case, I need to...

Ok, great. :) I find a way to debug this PR, so, I'll test it during the night and I'll push new commit tomorrow to this PR if it's OK....

Hi Dave, PR 391 from oxidized repo is mine too, it has been developed to work with this current PR. I didn't want manage Oxidized config in web project. :)...

I commited new stuff. PR contains all necessary things in order to use hide_enable in oxidized-web. ytti/oxidized#391 needs to be accepted too for configuring rest_hide_enable: true in oxidized config file....

Hello Dave, Thank you for testing my PRs anyway :) When you say: "Unfortunately i can still see the 'username priv 15 secret 5 blahblah' on all devices.", you speak...

Yeah, actually, /node/fetch/device_name page is not managed with rest_hide_enable. But remove_secret in vars normally removes stuff from backuped config showed on /node/fetch/device_name page. "Im assuming that if the backuped config...

You're welcome. :) rest_hide_enable just put 'HIDDEN' in HTTP result if you specified plain enable password in source var_maps like: ``` yaml # part of oxidized configuration file source: default:...