Password Protect LaunchPad Reset

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

Hi,

So far, we’ve only had distinctions between “write” users (reset, add, update, etc.) and “read” users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.

However, your use case is about “semi-write” users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for “semi-write” cases.

If you’d just like to make it more difficult for them to reset the database unintentionally, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the “current date” is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.

To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).

Best,

Anubhav

···

On Mon, Apr 6, 2015 at 5:07 PM, [email protected]ail.com wrote:

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/3a4e1a81-f370-4fb0-950c-07b5c812ea81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Thanks for the quick and very thorough response. It was really helpful. I think you’re right that this sort of credential administration should be done at the database level. From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use. Like I said before, the concern is with keeping a permanent record of all past and present fireworks and workflows. We want to maintain a record of what was done and make sure that no in process workflows are deleted. Are there any reasons that resetting the db would be necessary? Is there a better strategy for maintaining a record of previous work? I’m liking the capabilities of FireWorks so far, thanks a lot for all your time and effort.

···

On Tuesday, April 7, 2015 at 12:06:42 PM UTC-7, Anubhav Jain wrote:

Hi,

So far, we’ve only had distinctions between “write” users (reset, add, update, etc.) and “read” users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.

However, your use case is about “semi-write” users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for “semi-write” cases.

If you’d just like to make it more difficult for them to reset the database unintentionally, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the “current date” is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.

To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).

Best,

Anubhav

On Mon, Apr 6, 2015 at 5:07 PM, [email protected] wrote:

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/3a4e1a81-f370-4fb0-950c-07b5c812ea81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use

Do you happen to know where you read this? I looked casually and didn’t see such an account. One of the issues in maintaining such privileges is that calling the update() command essentially also allows you to remove documents, since you can always update to an empty document. So it is difficult to design a user that can update() but cannot remove().

Are there any reasons that resetting the db would be necessary?

Generally one only needs to do this to initialize the database. However, in the beginning when people are first developing workflows and debugging, it is common that they reset often. Once they go into “production” they stop resetting.

Is there a better strategy for maintaining a record of previous work?

Our own strategy generally consists of the following:

i) Back up the FW database frequently via mongodump

ii) Trust people not to call reset() along with the (obvious) daily passcode. It is the same kind of trust that they won’t overload the DB with workflows or manually log into the Mongo shell and delete everything.

One could also have separate FW databases for each user. Then at least user A can’t wipe out user B. However, then each user will need their own infrastructure for calling rlaunch, qlaunch, etc. rather than a “common pot” of calculations.

Another solution is to only give out read-only passwords to your users. If users want to add workflows, you can expose a service that lets them call a function to do this, without having the direct MongoDB password to the FW database. There would be no function exposed to reset workflows.

Again, there are a few other things that could be done to make reset() more difficult for people, but I’m wondering if they are overly complex and anyway not secure.

Best,

Anubhav

···

On Tue, Apr 7, 2015 at 3:31 PM, [email protected] wrote:

Thanks for the quick and very thorough response. It was really helpful. I think you’re right that this sort of credential administration should be done at the database level. From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use. Like I said before, the concern is with keeping a permanent record of all past and present fireworks and workflows. We want to maintain a record of what was done and make sure that no in process workflows are deleted. Are there any reasons that resetting the db would be necessary? Is there a better strategy for maintaining a record of previous work? I’m liking the capabilities of FireWorks so far, thanks a lot for all your time and effort.

On Tuesday, April 7, 2015 at 12:06:42 PM UTC-7, Anubhav Jain wrote:

Hi,

So far, we’ve only had distinctions between “write” users (reset, add, update, etc.) and “read” users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.

However, your use case is about “semi-write” users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for “semi-write” cases.

If you’d just like to make it more difficult for them to reset the database unintentionally, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the “current date” is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.

To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).

Best,

Anubhav

On Mon, Apr 6, 2015 at 5:07 PM, [email protected] wrote:

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/3a4e1a81-f370-4fb0-950c-07b5c812ea81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/6e5912b1-efbf-45ab-a768-fc107d691ee8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

That all makes sense. When configuring and testing, reset is definitely necessary. You also have to trust the user to a certain degree but I prefer minimum necessary privileges. At the very least full db wipes for us need to have an acceptable level of security after live data is populated.

As of MongoDB 2.6 the admin can now create custom roles (http://docs.mongodb.org/manual/core/authorization/#user-defined-roles)

Pretty sure you can cherry pick from the complete list of user roles. (http://docs.mongodb.org/manual/reference/built-in-roles/)

···

On Tue, Apr 7, 2015 at 3:31 PM, [email protected] wrote:

Thanks for the quick and very thorough response. It was really helpful. I think you’re right that this sort of credential administration should be done at the database level. From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use. Like I said before, the concern is with keeping a permanent record of all past and present fireworks and workflows. We want to maintain a record of what was done and make sure that no in process workflows are deleted. Are there any reasons that resetting the db would be necessary? Is there a better strategy for maintaining a record of previous work? I’m liking the capabilities of FireWorks so far, thanks a lot for all your time and effort.

On Tuesday, April 7, 2015 at 12:06:42 PM UTC-7, Anubhav Jain wrote:

Hi,

So far, we’ve only had distinctions between “write” users (reset, add, update, etc.) and “read” users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.

However, your use case is about “semi-write” users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for “semi-write” cases.

If you’d just like to make it more difficult for them to reset the database unintentionally, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the “current date” is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.

To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).

Best,

Anubhav

On Mon, Apr 6, 2015 at 5:07 PM, [email protected] wrote:

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/3a4e1a81-f370-4fb0-950c-07b5c812ea81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/6e5912b1-efbf-45ab-a768-fc107d691ee8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Sorry to intrude, but just to add on reset functionality.
I would possibly go with simple config file including yaml having param for lpad or other wrappers that can specify if reset is locked or not. rest if if…else clause.

At least that is what I am doing wrapping fw api to my custom one fwDriver.

–sasha

···

On Friday, April 10, 2015 at 10:58:48 PM UTC-4, Aaron Scott wrote:

That all makes sense. When configuring and testing, reset is definitely necessary. You also have to trust the user to a certain degree but I prefer minimum necessary privileges. At the very least full db wipes for us need to have an acceptable level of security after live data is populated.

As of MongoDB 2.6 the admin can now create custom roles (http://docs.mongodb.org/manual/core/authorization/#user-defined-roles)

Pretty sure you can cherry pick from the complete list of user roles. (http://docs.mongodb.org/manual/reference/built-in-roles/)


Aaron

On Wed, Apr 8, 2015 at 12:47 PM, Anubhav Jain [email protected] wrote:

From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use

Do you happen to know where you read this? I looked casually and didn’t see such an account. One of the issues in maintaining such privileges is that calling the update() command essentially also allows you to remove documents, since you can always update to an empty document. So it is difficult to design a user that can update() but cannot remove().

Are there any reasons that resetting the db would be necessary?

Generally one only needs to do this to initialize the database. However, in the beginning when people are first developing workflows and debugging, it is common that they reset often. Once they go into “production” they stop resetting.

Is there a better strategy for maintaining a record of previous work?

Our own strategy generally consists of the following:

i) Back up the FW database frequently via mongodump

ii) Trust people not to call reset() along with the (obvious) daily passcode. It is the same kind of trust that they won’t overload the DB with workflows or manually log into the Mongo shell and delete everything.

One could also have separate FW databases for each user. Then at least user A can’t wipe out user B. However, then each user will need their own infrastructure for calling rlaunch, qlaunch, etc. rather than a “common pot” of calculations.

Another solution is to only give out read-only passwords to your users. If users want to add workflows, you can expose a service that lets them call a function to do this, without having the direct MongoDB password to the FW database. There would be no function exposed to reset workflows.

Again, there are a few other things that could be done to make reset() more difficult for people, but I’m wondering if they are overly complex and anyway not secure.

Best,

Anubhav

On Tue, Apr 7, 2015 at 3:31 PM, [email protected] wrote:

Thanks for the quick and very thorough response. It was really helpful. I think you’re right that this sort of credential administration should be done at the database level. From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use. Like I said before, the concern is with keeping a permanent record of all past and present fireworks and workflows. We want to maintain a record of what was done and make sure that no in process workflows are deleted. Are there any reasons that resetting the db would be necessary? Is there a better strategy for maintaining a record of previous work? I’m liking the capabilities of FireWorks so far, thanks a lot for all your time and effort.

On Tuesday, April 7, 2015 at 12:06:42 PM UTC-7, Anubhav Jain wrote:

Hi,

So far, we’ve only had distinctions between “write” users (reset, add, update, etc.) and “read” users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.

However, your use case is about “semi-write” users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for “semi-write” cases.

If you’d just like to make it more difficult for them to reset the database unintentionally, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the “current date” is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.

To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).

Best,

Anubhav

On Mon, Apr 6, 2015 at 5:07 PM, [email protected] wrote:

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/3a4e1a81-f370-4fb0-950c-07b5c812ea81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/6e5912b1-efbf-45ab-a768-fc107d691ee8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi,

Thanks for the link regarding custom roles. I guess you could certainly set up such a role manually by logging into your Mongo server (using your launchpad credentials), following the instructions in the link you sent to create a restricted role, and then distributing my_launchpad.yaml with that restricted role as the username/password rather than the admin user.

I am guessing you are looking for some kind of convenience function, e.g. “lpad adduser --restricted” which creates the Mongo role for you on the server-side and return back a “my_launchpad.yaml” that you could distribute to your team. If you are willing to write such a function yourself I’d be happy to merge it back into the main repo. I can guide you if needed. Otherwise, unfortunately I think I will need to leave this as a manual process unless there is a lot of demand for it.

···

On Monday, April 20, 2015 at 11:07:11 AM UTC-7, [email protected] wrote:

Sorry to intrude, but just to add on reset functionality.
I would possibly go with simple config file including yaml having param for lpad or other wrappers that can specify if reset is locked or not. rest if if…else clause.

At least that is what I am doing wrapping fw api to my custom one fwDriver.

–sasha

On Friday, April 10, 2015 at 10:58:48 PM UTC-4, Aaron Scott wrote:

That all makes sense. When configuring and testing, reset is definitely necessary. You also have to trust the user to a certain degree but I prefer minimum necessary privileges. At the very least full db wipes for us need to have an acceptable level of security after live data is populated.

As of MongoDB 2.6 the admin can now create custom roles (http://docs.mongodb.org/manual/core/authorization/#user-defined-roles)

Pretty sure you can cherry pick from the complete list of user roles. (http://docs.mongodb.org/manual/reference/built-in-roles/)


Aaron

On Wed, Apr 8, 2015 at 12:47 PM, Anubhav Jain [email protected] wrote:

From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use

Do you happen to know where you read this? I looked casually and didn’t see such an account. One of the issues in maintaining such privileges is that calling the update() command essentially also allows you to remove documents, since you can always update to an empty document. So it is difficult to design a user that can update() but cannot remove().

Are there any reasons that resetting the db would be necessary?

Generally one only needs to do this to initialize the database. However, in the beginning when people are first developing workflows and debugging, it is common that they reset often. Once they go into “production” they stop resetting.

Is there a better strategy for maintaining a record of previous work?

Our own strategy generally consists of the following:

i) Back up the FW database frequently via mongodump

ii) Trust people not to call reset() along with the (obvious) daily passcode. It is the same kind of trust that they won’t overload the DB with workflows or manually log into the Mongo shell and delete everything.

One could also have separate FW databases for each user. Then at least user A can’t wipe out user B. However, then each user will need their own infrastructure for calling rlaunch, qlaunch, etc. rather than a “common pot” of calculations.

Another solution is to only give out read-only passwords to your users. If users want to add workflows, you can expose a service that lets them call a function to do this, without having the direct MongoDB password to the FW database. There would be no function exposed to reset workflows.

Again, there are a few other things that could be done to make reset() more difficult for people, but I’m wondering if they are overly complex and anyway not secure.

Best,

Anubhav

On Tue, Apr 7, 2015 at 3:31 PM, [email protected] wrote:

Thanks for the quick and very thorough response. It was really helpful. I think you’re right that this sort of credential administration should be done at the database level. From the MongoDB documentation I’ve read, it seems possible to create a custom service account with no remove privileges that FireWorks could use. Like I said before, the concern is with keeping a permanent record of all past and present fireworks and workflows. We want to maintain a record of what was done and make sure that no in process workflows are deleted. Are there any reasons that resetting the db would be necessary? Is there a better strategy for maintaining a record of previous work? I’m liking the capabilities of FireWorks so far, thanks a lot for all your time and effort.

On Tuesday, April 7, 2015 at 12:06:42 PM UTC-7, Anubhav Jain wrote:

Hi,

So far, we’ve only had distinctions between “write” users (reset, add, update, etc.) and “read” users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.

However, your use case is about “semi-write” users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for “semi-write” cases.

If you’d just like to make it more difficult for them to reset the database unintentionally, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the “current date” is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.

To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).

Best,

Anubhav

On Mon, Apr 6, 2015 at 5:07 PM, [email protected] wrote:

Hi, is there a way to password protect resetting of the launchpad? In looking at lanchpad.py and lpad_run.py it seems as though the reset password is always set dynamically to today’s date and can be overridden on the cmd line by answering the input prompt correctly. I would prefer if our users could add and run workflows (insert/update) but not reset the db (remove) without proper credentials. Any thoughts? Should this be done at the db level, restricting user roles? This seems like somewhat of a common use case as we don’t want anyone wiping the database unintentionally.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/3a4e1a81-f370-4fb0-950c-07b5c812ea81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To view this discussion on the web visit https://groups.google.com/d/msgid/fireworkflows/6e5912b1-efbf-45ab-a768-fc107d691ee8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.