Issue 504: Client-side SSL certs

3 views
Skip to first unread message

Willy Mene

unread,
Jul 29, 2010, 3:07:18 PM7/29/10
to active...@googlegroups.com
Hey Matt,

Any idea when this can get implemented in ActiveFedora?
http://projects.mediashelf.us/issues/show/504

We use client-side certs to authenticate to our Fedora instances, and
we've been having to include this monkey patch to connect. We have an
older ruby library accessing fedora that we'd like to replace with
ActiveFedora, but I'd like to do it without having to include our patch.

If there's a cleaner way to turn this feature on and off, I'm open to
that too.

Thanks,
Willy

Matthew Zumwalt

unread,
Jul 30, 2010, 10:16:41 AM7/30/10
to active...@googlegroups.com
I'm sorry I've completely forgotten about this ticket.

Do we just need to apply the patch you've put in the ticket in order to support this?

Matt Zumwalt
MediaShelf, LLC




--
You received this message because you are subscribed to the Google Groups "ActiveFedora / Ruby + Fedora Commons" group.
To post to this group, send email to active...@googlegroups.com.
To unsubscribe from this group, send email to active-fedor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/active-fedora?hl=en.


Willy Mene

unread,
Jul 30, 2010, 2:09:18 PM7/30/10
to active...@googlegroups.com
I've cleaned up the patch in the ticket.  Just replace the Fedora::Connection#http method with the new method in the ticket.  Feel free to clean up as you see fit.

Willy

Chris Fitzpatrick

unread,
Jul 30, 2010, 4:20:44 PM7/30/10
to active...@googlegroups.com

Hey everyone,

This is a slightly weird one, so hopefully I can explain the issue properly.

In our Etd rails application, we're using an AF model called "Etd".
When this initially saves the object, it sticks "Etd" in the
"active_fedora_model" field.
This values is set with a self.class.inspect, so it's just sticking in
the class name in to this field. You all probably know this.

The problem arises later down stream. We have several script running to
do other processes on the objects outside of the rails application.
These scripts use the same model, but we had to move it into a module,
so it's not called Etd, but is now EtdModel::Etd.

So, the problem is, when AF tried to load an object, it looks at the
"active_fedora_model" ("Etd") field for its class, which is not defined
in this context.
Looking at the code (solr_service.rb), I realized I can set a Kernel
constant of "Etd" that points to the correct class.

Excellent! Oh wait, but no! If I set this constant, do some stuff, save
the object, and update the index, the active_fedora_model gets changed
to "EtdModel::Etd", which breaks the object in the
rails application (because it's still looking for the Etd class)

So, would it be possible to have AF look at constants defined when
saving? I guess this might be slightly tricky, because we'd need to look
for class value, rather than the constant name.
But, ideally, if I define a constant "Etd" that points to EtdModel::Etd,
AF will load the correct class when it finds active_fedora_model ==
"Etd" and save active_fedora_model as "Etd", even if
I'm using a class called EtdModel::Etd.

Or are there other solutions I'm not thinking of?
And does this even make sense?

(And, yes, we are going back and changing the application to use the
same class as the scripts downstream, which will fix the
problem...however, the issue of having to keep module and class names
consistent might be a little difficult long-term, since we're spreading
out shared models over different applications.)

thanks,chris.

Matthew Zumwalt

unread,
Aug 2, 2010, 1:50:55 PM8/2/10
to active...@googlegroups.com
Would it work to allow models to define a custom model_pid class attribute?  Then ContentModel.pid_from_ruby_class could use that value if it's set.  Example:

class   EtdModel::Etd
cmodel_pid  "afmodel:Etd"
end

.. or you could even point to a completely different pid ...

class   EtdModel::Etd
cmodel_pid "hydra:ThesisOrDissertation"
end


Matt Zumwalt
MediaShelf, LLC




Reply all
Reply to author
Forward
0 new messages