myexperiment-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Myexperiment-discuss] strategies for excluding username/password from l


From: James Howison
Subject: [Myexperiment-discuss] strategies for excluding username/password from logbook?
Date: Sun, 15 Jun 2008 10:31:26 -0400

Howdy,

We are preparing some workflows which require access to password protected databases. The data providers issue user/pass to researchers on request, mostly to monitor usage and load by account. We'd like the workflows to work against the databases, but when other researchers use them to have them provide their user/id. However we'd also like to publish the logbook results for the workflows with publications so that others can see all the intermediates etc (and eventually use the ontology elements to discover data/point or variable usage etc). Where ever possible we're trying to use standard components, like the SQL lookup component.

We'd like the user/pass not to show up in the results.

Currently I see three options:

user/pass as workflow inputs
user/pass as default values
user/pass as "ask for value" pop-up results

But all these show up in the logbook results.

I could wrap the components that need user/pass in a custom beanshell component and read them from the file system, but I think that limits the portability pretty badly. Even if there was a user properties file that could be read from inside a component that would limit the ability to use the standard SQL component (which takes user/pass as input and therefore always records it).

Is there a standard/recommended strategy for this? I searched the mailing list and myexperiment, and the strategy I saw most is to have user/pass as input variables, passed through to where they are needed; but that will record them in the workflow runs and make the runs less shareable.

Perhaps one could mark input/output ports as "to be obfuscated" for workflow/logbook records? Of course one would want to avoid that in general, but user/pass (especially pass :) is a special case, I think.

Thanks,
James




reply via email to

[Prev in Thread] Current Thread [Next in Thread]