Scrum status Adam Young May 14, 2010
by Adam Young
Sorry for missing the scrum:
Yesterday: Went to the Westford office, met with Todd. Finally met
Mike McCune. Survived both. Worked on the rubygem-rubzip spec file,
which is a big learnging experence for me. Upgraded it to 0.9.4, worked
around a bug, and then removed the work-around, as the bug is actually
in how buildr calls rubyzip. Got a quick response from the maintainer,
Kudos to Thomas Sondergaard.
Also, long discussion with Mike Bonnet about how he is weaving Mead into
Brew. Mead is an approach to dealing with Maven in order to support
that large quantities of JBoss projects that use Maven, and to deal with
the huge quantities of dependencies in a Maven Repo.
Some details are here:
https://fedoraproject.org/wiki/KojiMavenSupport
https://fedoraproject.org/wiki/Talk:KojiMavenSupport
Today: plan to patch buildr and finish up the rubyzip spec, and then
apply the lessons learned their (mostly how to deal with rpmlint errors
and warnings) to the other rpms in the buildr dependency list.
13 years, 11 months
Re: access control code questions
by Justin Harris
----- jesusr(a)redhat.com wrote:
> All,
>
>
> While investigating the ConsumerTest failure (thx Dmitri for fixing
> it)
> I started looking at the access control code and have some questions.
>
> AccessControlInterceptor.java
> ------------------------------
> * in invoke(MethodInvocation invocation) we cast invocation.getThis()
> to
> a AbstractHibernateCurator so we can get the entityType.
>
> Can the invocation type be anything other than a Curator? If so, we
> need to protect against this.
If we want to generalize this later, yes. But currently we are only binding this
interceptor to AbstractHibernateCurator subclasses, so this is fine for now.
>
> * the private method crudAccessControl(Object) takes in an object but
> always assumes that the passed in object is of type
> AccessControlEnforced.
> Any reason this method doesn't just take in AccessControlEnforced
> instead of Object?
Agreed - this can probably be cast earlier in the process.
>
> * inside the same method we make a call to
> ConsumerPrincipal.consumer(),
> shouldn't that be getConsumer()? I'm not a big fan of
> getters/setters
> but are we going down the route of not using them now?
> http://zeusville.wordpress.com/2007/07/25/java-getterssetters/ [1]
+1
>
> * this led me to the model classes which implement
> AccessControlEnforced,
> they all seem to call a static class: AccessControlValidator (ACV)
> which
> has a bunch of shouldGrantAccess(SomeModelObject accessed,
> (Consumer|Owner)).
>
> It seems like we're mixing two styles here, 1) where the model
> objects
> are smart i.e. know how to answer if they have access to something
> 2) using a helper class to make that decision.
>
> I'd prefer we pick one. Either have the model object inspect itself
> to answer the question shouldGrantAccessTo(Owner|Consumer) OR
> have the Interceptor call the ACV directly passing
> in the AccessControlEnforced object.
>
> The other concern with the current approach is the ACV cracks open
> the model object to determine the answer:
>
> public static boolean shouldGrantAccess(Pool accessed, Consumer
> consumer) {
> return accessed.getOwner().getConsumers().contains(consumer);
> }
>
> * Lastly the above code scares me too because of Hibernate.
>
> accessed.getOwner().getConsumers().contains(consumer);
>
> Doesn't this get the Pool's Owner, then gets loads ALL of the
> Owner's
> Consumers (fully populated object), to look in the Java Set for a
> given
> Consumer. When in reality you really want a simple select statement
> like
>
> select c.id from cp_pool p, cp_consumer c
> where p.owner_id = X AND
> and c.owner_id = p.owner_id
> and c.id = Y
>
> I have *NOT* verified what queries Hibernate will generate, so I
> might
> be on crack. I do know that this bit me before where it looked like
> a simple java call, and it was a nasty SQL mess underneath.
>
> [1] shameless self-promotion
It seems to me that it is the principal that defines who
is making the request, and so permission checks should be on the principal to see if they
can access a certain entity. This allows for other types of identifying things to define their permissions,
and also can cut out some of the casting assumptions made in the interceptors.
>
> --
> jesus m. rodriguez | jesusr(a)redhat.com
> principal software engineer | irc: zeus
> red hat systems management | 919.754.4413 (w)
> rhce # 805008586930012 | 919.623.0080 (c)
> +---------------------------------------------+
> | "Those who cannot remember the past |
> | are condemned to repeat it." |
> | -- George Santayana |
> +---------------------------------------------+
>
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
13 years, 11 months
access control code questions
by jesus rodriguez
All,
While investigating the ConsumerTest failure (thx Dmitri for fixing it)
I started looking at the access control code and have some questions.
AccessControlInterceptor.java
------------------------------
* in invoke(MethodInvocation invocation) we cast invocation.getThis() to
a AbstractHibernateCurator so we can get the entityType.
Can the invocation type be anything other than a Curator? If so, we
need to protect against this.
* the private method crudAccessControl(Object) takes in an object but
always assumes that the passed in object is of type AccessControlEnforced.
Any reason this method doesn't just take in AccessControlEnforced
instead of Object?
* inside the same method we make a call to ConsumerPrincipal.consumer(),
shouldn't that be getConsumer()? I'm not a big fan of getters/setters
but are we going down the route of not using them now?
http://zeusville.wordpress.com/2007/07/25/java-getterssetters/ [1]
* this led me to the model classes which implement AccessControlEnforced,
they all seem to call a static class: AccessControlValidator (ACV) which
has a bunch of shouldGrantAccess(SomeModelObject accessed, (Consumer|Owner)).
It seems like we're mixing two styles here, 1) where the model objects
are smart i.e. know how to answer if they have access to something
2) using a helper class to make that decision.
I'd prefer we pick one. Either have the model object inspect itself
to answer the question shouldGrantAccessTo(Owner|Consumer) OR
have the Interceptor call the ACV directly passing
in the AccessControlEnforced object.
The other concern with the current approach is the ACV cracks open
the model object to determine the answer:
public static boolean shouldGrantAccess(Pool accessed, Consumer consumer) {
return accessed.getOwner().getConsumers().contains(consumer);
}
* Lastly the above code scares me too because of Hibernate.
accessed.getOwner().getConsumers().contains(consumer);
Doesn't this get the Pool's Owner, then gets loads ALL of the Owner's
Consumers (fully populated object), to look in the Java Set for a given
Consumer. When in reality you really want a simple select statement like
select c.id from cp_pool p, cp_consumer c
where p.owner_id = X AND
and c.owner_id = p.owner_id
and c.id = Y
I have *NOT* verified what queries Hibernate will generate, so I might
be on crack. I do know that this bit me before where it looked like
a simple java call, and it was a nasty SQL mess underneath.
[1] shameless self-promotion
--
jesus m. rodriguez | jesusr(a)redhat.com
principal software engineer | irc: zeus
red hat systems management | 919.754.4413 (w)
rhce # 805008586930012 | 919.623.0080 (c)
+---------------------------------------------+
| "Those who cannot remember the past |
| are condemned to repeat it." |
| -- George Santayana |
+---------------------------------------------+
13 years, 11 months
Cucumber Changes And Conventions
by Devan Goodwin
- There is now a test config file you can use to point cucumber tests
against any host you like. Copy proxy/features/cucumber.conf.example
to proxy/features/cucumber.conf and edit accordingly. No config file =
default settings, localhost, 8443, admin/admin.
- @candlepin is now semi-immutable and for super admin credentials.
Now that we have live auth it's problematic to have tests
re-initializing it with different credentials as it's an instance
variable and a later When/Then or After block may try to use it
expecting it to be initialized for a super admin.
- Use the following to create an owner admin and login:
Given /^an owner admin "([^\"]*)"$/ do |username|
@username = username
@password = 'password'
@candlepin.create_user(@test_owner['id'], @username, @password)
end
Given /^I am logged in as "([^\"]*)"$/ do |username|
@owner_admin_cp = connect(username=username, password="password")
end
- Similarly to create a consumer and login:
When /I register a consumer "(\w+)"$/ do |consumer_name|
consumer = {
:consumer => {
:type => {:label => :system},
:name => consumer_name,
}
}
register_consumer(consumer)
end
Given /^I am logged in as consumer "([^\"]*)"$/ do |consumer_name|
@current_consumer_cp = @consumers[consumer_name]
end
- There's a few instance variables in play here:
@current_consumer_cp - Authenticated CP connection for last consumer
you logged in as.
@consumers - Hash of all authenticated CP connections for consumers
you've created, indexed by the consumer name you specify in your text.
(some tests need more than one consumer connection)
@current_owner_cp - Authenticated CP connection for last user you
logged in as. (aka owner admin)
- There is now a test owner created for each scenario in a Before
block, and deleted in an After. The delete will take care of cleaning
out any entitlements, pools, and consumers that were created within
that org. If you create any other orgs in your tests you should
remember to clean these up as well. In general try to use the test org
available as @test_owner whenever possible and this should mostly be
taken care of for you.
Some conventions:
- We're randomly capitalizing words in the features. This looks
strange and is confusing when you go to try and re-use an existing
regexp and you have no idea what capitalization might be in effect, so
it's near impossible to memorize. I propose we capitalize the first
words (Given And When Then) and do the rest lowercase.
- We should organize the _steps.rb files by domain subject matter, not
link them one to one with the features. Justin found this link:
http://wiki.github.com/aslakhellesoy/cucumber/feature-coupled-steps-antip...
This should help us know where to look for things to re-use.
- As jbowes proposed I think we should probably try to:
- Wrap vars in quotes in the regexes.
- Not regex out words that aren't variables.
- Try to have the regexps call reusable code methods. I'm not sure
how to organize where they live, I guess in the domain subject's
_steps.rb with the regexps?
Other ideas for organizing / cleanup?
Cheers,
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
13 years, 11 months
Integration with a C application
by Rich Megginson
I am interested in integrating my C application with Candlepin.
Specifically, I would like to be able to activate certain features in
the product if there is an entitlement for those features.
13 years, 12 months
buildr upgrade mess in Fedora
by Adam Young
With the upgrade to rubygems, buildr is now broken. The buildr team has
moved on to 1.4, which has a very different set of dependencies from
1.3. It is still in RC mode, so I don't think upgrading is a choice
just yet.
That leave backporting the changes in the SVN tree that addres this
issue. I'm working on that. How does that figure in to priority for
building candlepin? Is using the 1.3.5 version of gems acceptable fora
a Koji build, or do we need to F-12 current in order to make the build
process move forward?
14 years
FTE Server updates
by wes hayutin
I think there was confusion regarding QE and the FTE server. The only
requirement we've had is that changes in the servers code or
availability be announced on imanage-qe-list(a)redhat.com.
I think the confusion was from the one time test day we hosted two weeks
ago. I'm sure that updates have been made to the FTE server since the
test day, possibly not the candlepin build itself, but I'm a little
unclear how and why we're now being asked if we want the server
updated.
Either way, I dont want QE holding up IT or the candlepin team. If you
guys need to get something done, shoot from the hip. Just email us ;)
Our preference would be to have FTE use the latest git tag, however I
would not say its a requirement.
Hopefully this will clear up any confusion on our part, and get updates
deployed faster. If we need to freeze updates to FTE in the future we
will specifically ask for it. I'll make sure we're more clear once
we're complete.
Thanks
14 years
