Re: selenium tests
see below On 27/12/2006, at 3:09 PM, Brett Porter wrote: On 27/12/2006, at 2:08 PM, Brett Porter wrote: Hi, A few observations on these. Does anyone else have outstanding "todos" in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to "user authenticated" assertions failing. Fixed the fundamental problem, now it's just UI changes. Down to 14 :) Down to 5 (AccountSecurityTest, ProjectGroupTest). I'll look later. 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus- security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett 5) the continuum tearDown should not swallow exceptions (retthrow them, but that means changing the abstract selenium test case to throw it too)
Re: selenium tests
On 27/12/2006, at 2:08 PM, Brett Porter wrote: Hi, A few observations on these. Does anyone else have outstanding "todos" in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to "user authenticated" assertions failing. Fixed the fundamental problem, now it's just UI changes. Down to 14 :) 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus- security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett
selenium tests
Hi, A few observations on these. Does anyone else have outstanding "todos" in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to "user authenticated" assertions failing. 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus- security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett
Re: Projects are visible to a guest user with no roles
On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: If I remove all the roles from the guest user [1] and log out, I can still see everything from project groups down to build results. Is this being worked on already? [1] including the mysterious 'Guest' role, which, once removed, is not in the list of Available Roles This is also the case for authenticated users with no roles. http://jira.codehaus.org/browse/CONTINUUM-1082 -- Wendy
Re: "Add project group" button not protected from unauthenticated users.
there are a number of things along these lines that I noticed in an little audit of the action classes that I noticed. Once rahul and I get the key based refactor wrapped up I think we'll try and link up with some work jason has been kicking around to improve the UI and xmlrpc code interface and security wise in one swoop. jesse On 12/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 11/28/06, Christian Edward Gruber <[EMAIL PROTECTED]> wrote: > Hey. Just FYI, in the trunk the unauthenticated user (and other > logged-in, unempowered users) can create new project groups. Thanks, this appears to be fixed in the latest code. (The 'Add project group' button no longer appears.) -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: "Add project group" button not protected from unauthenticated users.
On 11/28/06, Christian Edward Gruber <[EMAIL PROTECTED]> wrote: Hey. Just FYI, in the trunk the unauthenticated user (and other logged-in, unempowered users) can create new project groups. Thanks, this appears to be fixed in the latest code. (The 'Add project group' button no longer appears.) -- Wendy
Re: Are passwords required?
On 26 Dec 06, at 10:58 AM 26 Dec 06, Jesse McConnell wrote: imo, yes :) only the administrator has the ability to make those decisions and they ought to be allowed to do it... Definitely, as it might be used in a small group, in an already secure environment. Assume the driver has a brain. Jason. we restrict it already that users are not by default allowed to make empty passwords but with a but of configuration they should be allowed to not have passwords, if that is the admin's desire. also, admins can make passwords that don't follow the password conventions, but by default they are setup to be forced to make a password that does conform on first login jesse On 12/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: In 1.1-SNAPSHOT, on 'Create New User', I can create an account with no password, even though the two password fields have asterisks displayed next to them. If I then edit the user and uncheck the 'Change Password Next Login' box, the user can log in without a password. Should this be possible? -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: Are passwords required?
imo, password fields must be filled if they have the * as mandatory On 12/26/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: imo, yes :) only the administrator has the ability to make those decisions and they ought to be allowed to do it... we restrict it already that users are not by default allowed to make empty passwords but with a but of configuration they should be allowed to not have passwords, if that is the admin's desire. also, admins can make passwords that don't follow the password conventions, but by default they are setup to be forced to make a password that does conform on first login jesse On 12/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > In 1.1-SNAPSHOT, on 'Create New User', I can create an account with no > password, even though the two password fields have asterisks displayed > next to them. > > If I then edit the user and uncheck the 'Change Password Next Login' > box, the user can log in without a password. > > Should this be possible? > > -- > Wendy > -- jesse mcconnell [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: New User Registration problems
hehe, please file jira issue On 12/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: I'm having trouble with new user registration. (The creation->verification->change password flow works, but so do some things that shouldn't.) 1. Register for an account 2. Ignore the confirmation email 3. Attempt to log in with the new userid. Leave the password blank 4. You are prompted to 'Change Password' 5. Leave the 'existing password' blank, and enter a new password (twice). 6. You are logged in and on the Edit Details screen 1a. The newly created account is not "Locked" (even though the registration confirmation page says it will be.) 1b. Even if you log in as admin and lock the account, steps 3-5 still work. 4a. If you navigate away from the change password page without completing it, you appear to be logged in and can see everything from project groups down to build results. (Possibly related to [1] where a guest user with no roles can also see everything.) [1] http://www.nabble.com/Projects-are-visible-to-a-guest-user-with-no-roles-t2873616s177.html -- Wendy -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Are passwords required?
On 12/26/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: imo, yes :) only the administrator has the ability to make those decisions and they ought to be allowed to do it... Works for me, but let's fix the UI so the password fields are not marked with an asterisk if they're not actually required. Thanks, -- Wendy
Re: Are passwords required?
imo, yes :) only the administrator has the ability to make those decisions and they ought to be allowed to do it... we restrict it already that users are not by default allowed to make empty passwords but with a but of configuration they should be allowed to not have passwords, if that is the admin's desire. also, admins can make passwords that don't follow the password conventions, but by default they are setup to be forced to make a password that does conform on first login jesse On 12/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: In 1.1-SNAPSHOT, on 'Create New User', I can create an account with no password, even though the two password fields have asterisks displayed next to them. If I then edit the user and uncheck the 'Change Password Next Login' box, the user can log in without a password. Should this be possible? -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
New User Registration problems
I'm having trouble with new user registration. (The creation->verification->change password flow works, but so do some things that shouldn't.) 1. Register for an account 2. Ignore the confirmation email 3. Attempt to log in with the new userid. Leave the password blank 4. You are prompted to 'Change Password' 5. Leave the 'existing password' blank, and enter a new password (twice). 6. You are logged in and on the Edit Details screen 1a. The newly created account is not "Locked" (even though the registration confirmation page says it will be.) 1b. Even if you log in as admin and lock the account, steps 3-5 still work. 4a. If you navigate away from the change password page without completing it, you appear to be logged in and can see everything from project groups down to build results. (Possibly related to [1] where a guest user with no roles can also see everything.) [1] http://www.nabble.com/Projects-are-visible-to-a-guest-user-with-no-roles-t2873616s177.html -- Wendy
Are passwords required?
In 1.1-SNAPSHOT, on 'Create New User', I can create an account with no password, even though the two password fields have asterisks displayed next to them. If I then edit the user and uncheck the 'Change Password Next Login' box, the user can log in without a password. Should this be possible? -- Wendy
Re: svn commit: r490000 - in /maven/continuum/branches/key-based-refactor/continuum-store/src/test/java/org/apache/maven/continuum/store: AbstractContinuumStoreTestCase.java ContinuumStoreTest.java
On 12/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: rinku
Date: Sun Dec 24 00:12:41 2006
New Revision: 49
URL: http://svn.apache.org/viewvc?view=rev&rev=49
Log:
o updates to store unit tests for refactorings.
Modified:
@@ -896,7 +902,9 @@
{
try
{
-store.getProject( project.getId() );
+// TODO: Review! Since the Project key is unique only within a
group
+// shouldn't we specify the Group Key as well for deletion.
+store.getProject( new GroupProjectKey(null, project.getKey() ) );
fail( "Project should no longer exist" );
}
catch ( ContinuumObjectNotFoundException expected )
yes, most definitely we need to make sure these checks pull the group
key into context, otherwise we'll end up with arrays of results
instead of a particular unique project. I was just looking for
instances of this when I saw your comment so happy we both had it in
mind.
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
