[ https://issues.jboss.org/browse/JBDS-1583?page=com.atlassian.jira.plugin.... ] Libor Zoubek updated JBDS-1583: ------------------------------- Attachment: auth_error.png -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBDS-1583?page=com.atlassian.jira.plugin.... ] Libor Zoubek updated JBDS-1583: ------------------------------- Workaround Description: The workaround is to remove https://devstudio.jboss.com/updates/4.0/ updatesite and add it again. Another workaround is to go to Preferecnes -> Available Software Sites, select an update site and hit 'Reload'. This raises dialog for entering credentials. was:The workaround is to remove https://devstudio.jboss.com/updates/4.0/ updatesite and add it again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBDS-1583?page=com.atlassian.jira.plugin.... ] Libor Zoubek commented on JBDS-1583: ------------------------------------ Restart does not have effect. Once I enter credentials, it works. I think, problem is, that above updatesites are added by installer/build with (of course) no credentials. Once I provide credentials using one of workaround, I can access sites and install. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBDS-1583?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-1583: ---------------------------------- Did not see this when verifying JBDS-1580. Might be because I already have correct credentials cached in secure storage db which is shared amongst eclipse installs (in ~/.eclipse/org.eclipse.equinox.security/secure_storage) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBDS-1583?page=com.atlassian.jira.plugin.... ] Nick Boldt edited comment on JBDS-1583 at 3/2/11 4:54 PM: ---------------------------------------------------------- One workaround here would be to move the update site to an unprotected but obscurely named folder, like https://devstudio.jboss.com/updates/4.0-SDSDFHLIK23I487IDSFKLWDRUWREF1238... then rather than publish the URL, we give people a zip, like the one attached. To get updates, they'd manually add the zip via Help > Install new software > Add > Archive > browse for the zip. This would give them the URL of the site, but buried in a zip file we could put in the CSP. No typing, no passwords, etc. Only drawback is that the /updates/4.0/ URL would therefore be empty. In future, we could look at a plugin in JBDS that could somehow resolve credentials from the CSP and use that to get a per-user update site URL which they could use. Similar to the contents of the zip, we would GENERATE a folder like http://access.redhat.com/whatever/something/something/nboldt@redhat.com/j... which would contain the composite metadata pointing at the real location of the site. This is as secure as having a public registration form to get the username/password, in that it could be just as easily blogged/shared and therefore circumvented. was (Author: nickboldt): One workaround here would be to move the update site to an unprotected but obscurely named folder, like https://devstudio.jboss.com/updates/4.0-SDSDFHLIK23I487IDSFKLWDRUWREF1238... then rather than publish the URL, we give people a zip, like the one attached. To get updates, they'd manually add the zip via Help > Install new software > Add > Archive > browse for the zip. This would give them the URL of the site, but buried in a zip file we could put in the CSP. No typing, no passwords, etc. Only drawback is that the /updates/4.0/ URL would therefore be empty. In future, we could look at a plugin in JBDS that could somehow resolve credentials from the CSP and use that to get a per-user update site URL which they could use. Similar to the contents of the zip, we could have http://access.redhat.com/whatever/something/something/nboldt@redhat.com/j... which would contain the composite metadata pointing at the real location of the site. This is as secure as having a public registration form to get the username/password, in that it could be just as easily blogged/shared and therefore circumvented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira