One Star

Change tContextDump's Hide Password be encrypted rather than garbage

As a new user, a big problem I am seeing facing TOS is an inability to easily work with encrypted passwords.
Contexts denoted as "password" get encrypted by TOS inside of a properties file for the job.
If I create a tContextDump -> tFileOutputProperties connection, however, I only have two options: asterisks, or plain text.
It would be really nice if it used the same encryption scheme as for its native context properties... instead of asterisks.
Why?
Most people are using TOS to connect to a database... or something that requires a password.  You need to get that password into the system some how.  The most secure way to get that password would be from a prompt, possibly a tMsgBox, and then encrypt it and save it to the file.  Since you are probably reading this file into a context via tContextLoad to get the rest of your connection settings, it would be nice to write to it via tContextLoad.  This is especially handy for creating the properties file initially since there does not appear to be a documented way to embed a .properties file into a "build".  This would also shield me from having to encrypt the password myself... to which I have not found any documentation on how to encrypt passwords in a way that TOS can read using their existing encryption scheme.
1 REPLY
Fifteen Stars

Re: Change tContextDump's Hide Password be encrypted rather than garbage

As a new user, I am sure you understand that there is a lot that you do not know about the product yet. From what you have said (if I understood everything you were getting at), I can assure you that there are many ways to achieve the security you require. What you are seeing when you first use Talend is a basic framework which provides a lot of options for many areas of DI, but does not offer them all in an "out of the box" way. One very powerful thing about Talend is the ability to implement custom requirements via your own Java code and third party APIs. You have to think of Talend as an open framework which can be used with other frameworks and not as a closed source offering that will only support what has been thought of by the vendor. 
I have worked in DI for some time and have gone from writing solutions in pure SQL, to SQL with bits of code, to Informatica and similar tools, to Talend. In my opinion, Talend offers the most complete solution largely because I can add to it in any way I like, using any APIs I can make use of. Granted, that might not be for everyone, but it is certainly not a limitation. 
Another good thing about Talend is that their R&D teams are always open to implementing functionality that may be useful "out of the box". If you think that your requirement is a good idea (from my point of view it does seem to make sense to allow this sort of functionality without making users build in their own solutions), then you can raise a feature request with them.
Rilhia Solutions