Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DB00C97E3 for ; Tue, 7 Feb 2012 19:36:36 +0000 (UTC) Received: (qmail 65758 invoked by uid 500); 7 Feb 2012 19:36:36 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 65651 invoked by uid 500); 7 Feb 2012 19:36:35 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 65639 invoked by uid 99); 7 Feb 2012 19:36:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2012 19:36:35 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a41.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2012 19:36:27 +0000 Received: from homiemail-a41.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a41.g.dreamhost.com (Postfix) with ESMTP id 44A4644C062; Tue, 7 Feb 2012 11:36:07 -0800 (PST) Received: from [192.168.0.2] (unknown [151.67.87.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: andrea@pescetti.it) by homiemail-a41.g.dreamhost.com (Postfix) with ESMTPSA id 8C9AE44C05D; Tue, 7 Feb 2012 11:36:06 -0800 (PST) Message-ID: <4F317D23.8070201@apache.org> Date: Tue, 07 Feb 2012 20:36:03 +0100 From: Andrea Pescetti User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: Can we move forward with shutting down the openoffice.org email forwarder? References: <784BC6FB-5D1B-4FF4-B87A-1179E4BED132@comcast.net> <4F30E81D.6060907@apache.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07/02/2012 Rob Weir wrote: > On Tue, Feb 7, 2012 at 4:00 AM, Andrea Pescetti wrote: >> 2) Very likely the Drupal system on Extensions and Templates, upon >> successful login, duplicated usernames. This is why you see "pescetti" at >> http://extensions.services.openoffice.org/en/node/1204/releases ; however, >> it didn't duplicate passwords or e-mail addresses. > So we think that the Drupal app used EIS for authentication? Whatever it used, the login page on the Extensions site http://extensions.services.openoffice.org/user dies with "The login is currently not possible: http://eis.services.openoffice.org/ - HTTP/1.1 404 Not Found". >> 3) The authentication mechanism on Extensions and Templates is changed so >> that usernames are kept, but passwords and e-mail addresses are stored in >> the local database instead of being retrieved from the (unavailable) >> openoffice.org web services. Of course, we only have valid usernames at this >> point, not passwords or e-mail addresses. > Are you saying that this has already been done? Or are you saying > that this should be done? It should be done. I was listing steps. As far as I know, this didn't happen yet, otherwise the login page would not show the error. > OK. So you are essentially saying that we need the forwarders to > continue in order to communicate with extension developers one more > time, to let them know that they need to reset their passwords. Yes, but the "one more time" bit is incorrect: until the end of December, users could login but couldn't change their e-mail address or password (due to the single-sign-on being active); after the end of December, users have not been able to login at all. So the Extensions site users never had the possibility to change their password. >> in order to upload a new version of the Italian dictionary I would have to >> create a new account, a new extension and upload my new release (and of >> course break extension updates on the client, i.e., breaking the update >> check in OpenOffice). > Updates are broken already, because of the loss of Berkley DB, right? > So with AOO 3.4 all extensions will need to be reinstalled and the > update mechanism going forward will need to be adapted. The fact that extensions will need to be reinstalled has little to do with this: in general, extensions updates do not follow the OpenOffice release cycle. So being able to update an extension properly on the website by creating a new release (as opposed to create a new duplicate extension and making the new releases there) will help. > So we'll want to wait until the > new server is ready for authors to login again, and then send the > temporary passwords. Then we can shut down the forwarder. > Does that make sense? It does, with the only (minor) correction that Drupal does not set temporary passwords but one-time login links, which is good for us since users would be taken straight to their profile page and (with some tweaks on the Drupal side) be forced to change their e-mail to something not in the username@openoffice.org pattern and at the same time choose a password. Regards, Andrea.