[
https://issues.jboss.org/browse/JBIDE-10490?page=com.atlassian.jira.plugi...
]
Rob Stryker commented on JBIDE-10490:
-------------------------------------
I've just tried a whole collection of different workarounds and hit dead-ends at
almost every turn. I tried changing the implementation of JBossServer to store in a
regular variable the new value until the server has been saved. Even this could fail if
two different pieces of code created a working copy at the same time, I thoght it was
worth a shot. Unfortunately, the editor for some reason cannot convert the
IServerWorkingCOpy into a JBossServer to access this method. At this point in the editor,
it never seems to convert properly, which is why almost all other "sections" are
using a ServerAttributeHelper to set properties inside the server.
I tried separating it out into a further utility class, single-use class, kinda ugly, but
even then, there were too many deficiencies. For example if a user changes something in
the editor, but in the end does not save it, this utility class will keep the
changed-but-not-saved value. The next save, on any part of the server model, will also
have it persist this, even if password wasn't changed on the next edit.
There are entirely too many deficiencies here...
do not store server passwords in plain text
-------------------------------------------
Key: JBIDE-10490
URL:
https://issues.jboss.org/browse/JBIDE-10490
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Blocker
Fix For: 3.3.0.Beta1
last time we looked at this passwords were still being stored "unsafely" -
opening this to make sure we get that fixed by using eclipse's secure storage apis
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira