InputType does not work

[jasgrider]

Under change script parameter I am attempting to mask a password field that my script requires. I'm not getting what I would expect and its not masking anything in the final page.

Does this use the built in Django widgets in this field to describe how something is rendered as its input? I would expect to get *** or similar when I set that field to password based upon the django docs . I tried a couple of different ways to define that field but it always renders as input=text in the html.

Thanks!

[Chris7]

Hi @jasgrider,

The limitations of the GUI is reflected by the limitation of the parsers. Argparse doesn't support indicating password fields (you have to customize that). I'm not sure about other CLI parsers. However, there is a merge request #175 that would allow you to customize the widgets to add a password type.

This isn't something I plan to support natively in Wooey because Wooey stores the values of fields in plaintext in the database (so jobs can be cloned/reran/etc). This would be a major security issue if we were to have password fields stored in plaintext, since it gives the illusion of safety.

[jasgrider]

Thank you for the explanation of why. I agree it would be a security hole. Is there a way to get a script to prompt a user through the console for certain passwords or do the scripts need to run hands-off with just the parameters given through argparse?

I have a couple of other ideas I may be able to use.

[Chris7]

The issue with that is scripts are run in remote celery workers. You can disable remote code execution by setting WOOEY_CELERY = False, which may allow users to enter sensitive information at the command line. Though this means:

1. all jobs will block the Wooey server (not good)
2. users will have to user the computer Wooey is running on (also not good) to enter information.

So scripts should be designed to be hands off (though nothing is preventing a script in a remote worker from stopping to wait for some user triggered action, like a SMS response). I'd be interested to hear what your other ideas are.

[jasgrider]

I have celery set to false for now and knew about those limitations (this is just running on my computer at this time). The scripts I've written are to setup, monitor, and delete packet captures off of firewalls. We don't currently use key based authentication for those devices so user/pass with a centralized AAA server.

• Moving to ssh key based auth for just the wooey server is an option. Their would be a wooey priv/pub SSH key on our devices. There some internal issues my people would have with that the first being we've not done key based on any network device yet in production.
• Hardcode the a generic user/pass in my script. This server would not be public or client facing and access would be limited to just a select network in our office. I don’t mind this idea as I can do it pretty easily from both the script and the AAA server.
• probably some other thing I'm not thinking of this morning.

My intention was to use Wooey to make a quick web interface for users to start and stop the scripts. I'm not sure if that is the best option now but I was looking for quick and felt that if I could get it running in a few hours it would be worth further investigation.

Might be interesting to get Wooey to have a password/username field that it can put in its database but the encryption and decryption of that programaticly might be way out of its current scope. I've had to pull back a bit at the moment and drop back to running the scripts at the command line without a web interface.

[Chris7]

Another option would be to use something like this:

https://github.com/orcasgit/django-fernet-fields

and have some backend designation for when to use it. I'm not sure how that should look at this point though. I think for the time being, using option 2 with environment variables might be the easiest.