nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

How to manage password type form field

claudio_rosso

Hello,
I have to specify in a form task a password type field.
Is it possible to manage this kind of field without store the value to db and mantaining it in session until process is running?
If the application server must be restarted, then the user must enter the password again.

Thank you

Claudio Rosso

Find more posts tagged with

Comments

erikwinlof

See this thread for a previous discussion and ideas (not a solution) about non persistent variables
https://forums.activiti.org/content/using-non-persistent-variables-workflow-execution

Could you give some background on what you want to achieve exactly:
1. what shall happen when the password has been entered, i.e. how does your process look?
2. will it only be used directly after it was submitted or possibly multiple times?
3. Are you writing your own front end?
… just trying to take a step back and see if the solution could be handled partly outside of Activiti.

claudio_rosso

I have a simple workflow that allows authorized users to upload to an external repository encrypted confidential files.
The web application that handles sensitive data exposes the REST services stateless and authenticated.
The user, logs on to a user task, puts the information needed to start the REST service and among these is the authentication password for the service.
The requirement is to not store the password on the database (and even file system) but it is available only in session.

Yes, we are writing our frontend.

I thought to define a custom form field (not persistent string type) to manage this use case; could it be the solution?

Thanks

workflow.txt.zip

erikwinlof

Thanks!

I'm afraid I don't understand what you mean by "custom form field (not persistent string type)", would you mind elaborating?

A different alternative might be what I described below…

If I understand you correctly what you have is:
1. A webapp that you have written yourself that is using Activiti for workflows.
2. A repository that handles confidential files which exposes a REST api to upload documents into the repository.
What you are trying to do is make it possible from your web app to start a workflow which uploads some data to the repository using its REST api?

If so, I would focus on enhancing the integration between your webapp and the repository instead. In other words enhance the Service task that is running in the process to have a custom SSO integration against the repository api. This would also have the benefit of your webapp users not having have to supply the password information for the repository assuming they are logged in in the webapp and the same username is used both inside your webapp and the repository.

I.e.
1. User logs into the webapp
2. User fills in the form for the user task and provides the data that shall be uploaded to the repository (but the username of password is not entered)
3. The ServiceTask (it.awtech.activiti.AWDocMailConsumerService) is runned:
a) Instead of taking the username and password from the process variables the username is taken from the user running the process
b) Some kind of custom SSO logic is done for the repository rest api making a password not necessary.
c) The service tasks calls the repository rest api with some sort of SSO token representing the user which the repository api accepts.

Would this work? if you want some ideas for the SSO solution just send a reponse.

Cheers, Erik

claudio_rosso

Thanks to you.
Sorry for my english, with "custom form field (not persistent string type)" I mean "custom form property type", not stored on database, in addition to the form property types already supported (i.e string, long …).
You understand correctly the use case.
The alternative you described (SSO integration) is correct, and that's what we will do in the second phase of the project with regard to authentication mechanisms.
In the first phase of the project, however, we need to use a temporary solution, and in any case the password of the mailbox from which the mails are read and taken attachments to be loaded into the repository, must not be stored on the database.

For this reason I was thinking of using a custom form property type to manage password value in a session object and not on the database.

Cheers

Claudio

erikwinlof

Hi again,

Ok, good luck w phase 2!

Regarding the mailbox passwords etc it sounds like a good idea to use the custom form types as you said.

You've probably seen it already but here posting a blog post form Joram about how to create such things, some of the information is about Activiti explorer but there is also info about adding a custom form type to the engine as well.
http://www.jorambarrez.be/blog/2013/03/13/creating-a-new-form-property-in-activiti/

So what you want is to add a custom form type that its mapped to a process variable.
http://activiti.org/userguide/index.html?#formProperties

Create your own class i.e. MailBoxFormType by extending org.activiti.engine.form.AbstractFormType and more specifically serialize the password in convertFormValueToModelValue(String propertyValue). I.e. hashing the password to a hashed value and return it so it gets stored as the value for the process variable and at the same time make sure to save the original password in a global map with the hashed value as the key.

Later when your custom Service is running it shall have access to the same global map and then take the password process variable (which will be hashed) and look up the original value from the global map using the hashed password as the key.

claudio_rosso

Thank you so much.
I will try.

Claudio