Jump to content
  • Upgrade breaks secure storage

    Assigned User Massimo Rabbi
    CategoryBug report
    ResolutionNo Change Required

    Upgraded from JSS 5.2 to 5.5 on Mac via DMG, when I tried to use the server connections, I kept recieving a 401 unauthorized message from JasperReports Server, that the password is blank.


    Testing repo worked fine but then loading tree failed


    I deleted all secure storage from the preferences and re-entered passwords, it worked fine then

    Attachments: issueDetails.zip

    User Feedback

    Recommended Comments

    Changed Status from New to Confirmed

    Changed Assigned User from - to @User_306070

    Hi Ernesto,the problems seems related to the Eclipse Secure Storage in MacOSX. I've found different topics on the net about it (ie: https://jira.appcelerator.org/browse/TISTUD-2218).I was able to verify and reproduce a similar issue to your one.Right now we are using the secure storage into the default/standard way. I will investigate and try to find a feasible solution/workaroud. I perfectly understand that deleting the secure storage and re-entering passwords can not be considered a long term solution.Just in case we should think to a standard custom solution, shared among the different platforms (Windows / Linux / Mac). Right now, the secure storage approach is a platform dependent. For example in MacOS X it relies on the system Keystore. Did you had any chance to try in Windows/Linux? Did you verified a similar issue?Best regards,Massimo.
    Link to comment
    Share on other sites

    Changed Resolution from Open to Suspended

    Changed Assigned User from @anonymous to @mrabbi

    Hi Ernesto. Since there seems not to be a real fix for the problem, given it is Eclipse related, I came up with a different solution. People can use the OS integration or the UI prompt for Secure Storage. But they can also customize the ability to use the Secure Storage or not. This information can be set by the Global Preferences page.Since the need for storing securely credentials is not always a must, if there start to be this kind of annoying problems, or user does not want to enter the password everytime (i.e: UI prompt), he can safely switch to the old way of having clear text passwords.I think for now this is enough.However I will put the bug in SUSPENDED, maybe in the future we will come up with a more fine solution or something shared among JSS and JRS for secure storage of the information.In this way we know it is a still "open" problem, but with acceptable workaround.
    Link to comment
    Share on other sites

    Changed Priority from Normal to Urgent

    Changed Reproducibility from Random to Always

    Changed Resolution from Suspended to Reopened

    Since the use of Secure Storage is the default for JSS, a fix for this is critical for anyone trying to create JRS server connections.I found a fix for this. See attached.
    Link to comment
    Share on other sites

    Changed Resolution from Reopened to Suspended

    Hi Sherman,the solution you proposed of deleting secure storage information was already being adopted as work-around by Ernesto, see comment #1.What we did was to give the ability to switch-off the secure storage of passwords since last 5.5.0 version.Actually I don't see any real fix, since it seems a behavior that is platform dependent (different OS integrations fragments do the job). Moreover it is more Eclipse related, you may have noticed the huge number of topics related to different secure storage issues while googling for a solution.The second approach proposed by Ernesto of using the "UI Prompt" mechanism is another possibility. It would end-up be the same/similar solution as if we provide a custom encryption module. At least after every JSS launch you will end-up asking for a potential "secure vault" access password, when using encrypted credentials.
    Link to comment
    Share on other sites

    Changed Resolution from Suspended to No Change Required

    Changed Status from Confirmed to Closed

    The initial idea of implementing a custom master password provider was discarded.Since the current solution of having the secure storage disabled by default, we put together a detailed documentation to explain how to handle and configure the secure storage usage, whenever required.The UI prompt password provider (priority 2) suites well the needs.The articled is right now published in the internal wiki, and after a review will be published also on the community wiki and linked in the Resources page of the Jaspersoft Studio project.The bug will be closed.
    Link to comment
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Create New...