[jbosstools-issues] [JBoss JIRA] Updated: (JBDS-1110) reconfigure .htaccess rules for devstudio.jboss.com

[ https://jira.jboss.org/jira/browse/JBDS-1110?page=com.atlassian.jira.plug... ] Nick Boldt updated JBDS-1110: ----------------------------- Issue Type: Task (was: Thirdparty Change) Component/s: updatesite Fix Version/s: 3.0.1.GA Affects Version/s: 3.0.0.GA Description: Problem ----------- Currently we host update site files and some Early Access (EA) JBoss Dev Studio (JBDS) installers (.jar) on http(s)://devstudio.jboss.com. Everyone using the site shares the same access, which is somewhat painful for several reasons: a) No one can "discover" what's on the site because the root folder is restricted. b) EA users and existing registered JBDS users may not be the same folks; in fact, we may want to provide *FREE* EA access to encourage people to try-before-buy the forthcoming JBDS release, independent of possibly being an existing subscriber. c) Each annual release of JBDS gets a year of updates, but only for the product for which they subscribed; thus each year's update site should be differently restricted rather than using the shared across-the-board login. Ideally, username/password restriction would be fed by information in the CSP so that users would only need a single login, which would expire the minute their subscription expired, rather than using shared passwords via .htaccess; however, that requires significantly (?) more effort than the solution proposed below. Solution ----------- a) remove .htaccess username/password restriction for these folders: http://devstudio.jboss.com/ http://devstudio.jboss.com/updates/ http://devstudio.jboss.com/earlyaccess/ b) add .htaccess username/password restriction for these folders: http://devstudio.jboss.com/updates/2.1/ (use existing username/password) http://devstudio.jboss.com/updates/3.0/ (create new username/password) http://devstudio.jboss.com/earlyaccess/builds/ (use existing username/password + create second new username/password) I will send the current login details & proposed new ones along in an email to helpdesk@ so that they're not copied publicly here. Note that JBDS 3.0 is scheduled to be released March 10, and we need to get these changes in place before then. was: Problem ----------- Currently we host update site files and some Early Access (EA) JBoss Dev Studio (JBDS) installers (.jar) on http(s)://devstudio.jboss.com. Everyone using the site shares the same access, which is somewhat painful for two reasons: a) No one can "discover" what's on the site because the root folder is restricted. b) EA users and existing registered JBDS users may not be the same folks; in fact, we may want to provide *FREE* EA access to encourage people to try-before-buy the forthcoming JBDS release, independent of possibly being an existing subscriber. c) Each annual release of JBDS gets a year of updates, but only for the product for which they subscribed; thus each year's update site should be differently restricted rather than using the shared across-the-board login. d) Ideally, username/password restriction would be fed by information in the CSP so that users would only need a single login, which would expire the minute their subscription expired, rather than using shared passwords via .htaccess; however, that requires significantly (?) more effort than the solution proposed below. Solution ----------- a) remove .htaccess username/password restriction for these folders: http://devstudio.jboss.com/ http://devstudio.jboss.com/updates/ http://devstudio.jboss.com/earlyaccess/ b) add .htaccess username/password restriction for these folders: http://devstudio.jboss.com/updates/2.1/ (use existing username/password) http://devstudio.jboss.com/updates/3.0/ (create new username/password) http://devstudio.jboss.com/earlyaccess/builds/ (use existing username/password + create second new username/password) I will send the current login details & proposed new ones along in an email to helpdesk@ so that they're not copied publicly here. Note that JBDS 3.0 is scheduled to be released March 10, and we need to get these changes in place before then. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira