I have taken the cosign module and created a "cosign_auth" module that works on Drupal 7. This module is not dependent on the webserver_auth module and does not use or rely on the authmap table.
NOTE: this module was derived from the cosign.module.
* you must be running your server within a cosign infrastructure.
More info at: http://www.weblogin.org/
* download the cosign_auth module
* copy the module into your drupal modules directory
* enable the module through the ?q=admin/build/modules page
* configure the module through the ?q=admin/config/system/cosign_auth page
* add the logout block to your page with the ?q=admin/build/block page
The cosign_auth module is not dependent on any other contributed modules, it
does not use the webserver_auth module and does not use or rely on the authmap
table.
For those wondering why I did not pursue upgrading the current cosign module that relies on the webserver_auth module, here's my reasons (notice I didn't say they were good reasons!):
* there is no Drupal 7 version of the webserver_auth module
* the webserver_auth module hasn't been updated since 2008, Maintenance is "minimally maintained"
* the purpose of the webserver_auth module is to permit each user to be assigned a "different" authentication method - this had little value for campus Single-Sign-On Drupal projects I'm involved where the desire is to use a SSO.
Comments
Comment #1
meba commentedI don't believe we review code outside Drupal.org Git repository. Please see: http://drupal.org/node/1011698
Comment #2
tr commentedPersonally, I think the community would be better served if you helped the cosign project move forward by asking to be a co-maintainer so you can port it to D7. I don't see that a port to D7 has even been the subject of a question in the cosign issue queue, so it's hard to know what the current maintainer's plans are. But asking should be the first step.
Cosign is dependent on webserver_auth, so if webserver_auth is holding you back, you can become a co-maintainer for it too. In that module's issue queue I found a thread where the community has already contributed a D7 port and the current maintainer says "I would welcome a co-maintainer." See http://drupal.org/node/991922#comment-4217590
By helping out with existing projects, porting them to D7 and adding new features, you help all the people who are currently using those projects, as well as yourself. And we all get better the code when there are more people testing and reporting bugs - this is especially important with projects that involve sign-on authentication.
Comment #3
bob.riddle commentedI thought this sandbox code was in the Drupal GIT repository. At least I went through the git-dance to create & upload the code to the Drupal sandbox:
http://drupalcode.org/sandbox/bob.riddle/1118948.git/tree/3654fcc
Did I not do this correctly? If so, any further instruction will be appreciated!
Comment #4
bob.riddle commentedFor folks I've communicated with using the cosign module, the webserver_auth module is installed with cosign because it is required, not because is desired, wanted, or needed. For such folks, it also imposes unneeded/unrequired integration with the authmap table.
I was trying to contribute to the community by taking the current D6 cosign module and porting it to D7 in a manner most suitable to the cosign community I had talked with. Not wanting to impose on those planning to upgrade the current cosign module along with the webserver_auth module, I decided to call this cosign_auth.
On the up side, anyone compelled to upgrade the current cosign & webserver_auth module are welcome to take advantage of the D7 compatiable cosign_auth code.
I must confess the reason I've jumped through all the "sandbox, make it a drupal project" hoops is due to colleagues using Cosign at universities badgering me to jump through these hoops. If the Drupal community determines this is not worthy of being a project I can remove my "hoop-jumping" shoes without regret or resentment.
Comment #5
sreynen commentedThe sandbox project is here: http://drupal.org/sandbox/bob.riddle/1118948
Comment #6
bob.riddle commentedIf your institution is currently using the Cosign module for Drupal 6, please comment!
Comment #7
ralt commentedChanging priority according to the new priority guidelines.
Comment #8
clayball commentedThis module works well.. so far at least.. I haven't fully tested.
The one feature I think is missing is to allow anonymous access. Currently the entire site is required to be cosign protected which means only those people with a cosign login can access the site.
Comment #9
tr commentedAs I said in #2, I'm against forking the existing cosign module and I strongly encourage the OP to take over or become a co-maintainer of the existing module in order to move it forward. I would mark this as closed (won't fix) if it were up to me. I would like to hear what the maintainer of the existing cosign module has to say on this topic. Has the OP made an effort to contact him/her?
Comment #10
sreynen commentedTo summarize, this module duplicates the functionality of these two combined:
http://drupal.org/project/cosign
http://drupal.org/project/webserver_auth
bob.riddle, you wrote previously that your motivation for splitting off a new project was "not wanting to impose on those planning to upgrade." Your contribution shouldn't be an imposition at all. Collaboration is a core principle of Drupal. Please consider contacting them about using your code in a D7 version rather than splitting into two separate projects that do the same thing.
To be clear, the issue here is not whether or not your hoop-jumping contribution is appreciated; it certainly is. We just want to make sure it is used in a way that minimizes future hoop-jumping for both contributors and users, yourself included.
Please change this back to "need review" when you respond.
Comment #11
avpadernoComment #12
bob.riddle commentedI sent a message to mlhess & ksteinhoff, the active maintainers of the cosign module for Drupal 6.
Given that I began working with this code, I'd be happy to try & integrate my Drupal 7 changes with this module.
I'm also interested in their perspective about the current dependency on the webserver_auth module.
Comment #13
bob.riddle commentedComment #14
ksteinhoff commentedbob.riddle, thank you for pointing me to this thread.
I agree with those who've said it would be better to not fork the project. I know some people have done work to port the cosign module to D7, but that work hasn't been committed to the module's repository yet.
I've talked to a number of people who'd prefer to remove the dependency on webserver_auth and I think I agree that that's a good idea. This is probably a perfect time for that discussion, it just hasn't happened yet. Is this thread the right place for it? Maybe it would be better to create an issue in the cosign module's project page? Either way I'll do my best to direct the developers I know towards it the discussion to get as much input as possible.
Comment #15
uhs commentedHi everyone. I agree with merging this into the current cosign module and not forking. With so few people working on the cosign module it would be a pity to fork, because a lot of effort may be duplicated as opposed to working together on a single module. We have several D6s with Cosign + webserver auth, and LDAP group roles.
Have the original cosign module devs done any coding to make it work with D7? Did they have plans to? I hope it is feasible to combine these two into one. Let me know if you'd like any assistance. Thanks for your work on this.
Comment #16
klausiOk, so please talk to the cosign maintainers. Reopen if still think you need this application.
Comment #17
bob.riddle commentedI sent email to the consign developers and have never received a response. I've assisted several departments at UM in deploying Drupal 7 using this cosign module (remember, the old one is not Drupal 7 "friendly"!)
I think this should be made available as a "choice" for people that want to use Drupal 7 but are required to use Cosign.
Comment #18
bob.riddle commentedI was told to reopen this if I thought it of value.
Comment #19
sreynen commentedComment #20
jthorson commentedbob,
Since ksteinhoff already indicated at least an interest in collaborating in comment #14 above, can you open a ticket in the Cosign issue queue, asking to become a co-maintainer? Some maintainers may discourage communication by email, but will respond to issues in their project issue queue ... it's easy to decide to 'respond later' to an email and then forget, whereas a ticket in the issue queue is a little harder to lose.
In addition, this approach leaves a more public 'paper trail', allowing independent verification that the question was asked and went unanswered.
The other reason to take this approach is that, if the existing maintainers are not responding in the queue, your ticket would then satisfy the first step in the abandoned module process ... which you could use to take over the cosign project, and deploy the D7 version under the existing project name.
So, as a next step, I'd propose:
... both of which result in a single choice for end users, and allow users of the D6 Cosign module to easily locate the potential upgrade path to your project.
Comment #21
jthorson commentedOoops ... didn't mean to mark this postponed before soliciting your thoughts on this approach!
Comment #22
misc commented@bob.riddle has been contacted to ask if the application is abandoned.
http://drupal.org/node/894256
Comment #23
BobRiddle commentedSorry I didn't see this until I was poked by mikke.schiren@nodeone.se to ask me if this was an abandoned project. I no longer have the time or the inclination to try and integrate this with the existing D6 cosign module. The D7 module has been used for D7 deployment on our UM campus. I can point you at the departments, if you'd like contact me via my UM email.
Any suggestions you have on how one might proceed are appreciated. There have been some new features and updates add to this module, which it did not occur to me to commit to the sandbox, since it seemed to me that unless this was integrated with the D6 module that it would not be accepted.
My colleagues encouraged me to submit this as a sandbox project, I'd be happy to continue to push this along in it's current form. This seems useful to me, since it is being deployed across our campus & is provided to any of our "friends" who ask for it.
Comment #24
BobRiddle commentedI'd be happy to place something in the "Cosign issue queue" ... if I can figure it out. I'm going to assume the issue I paced here (http://drupal.org/project/issues/cosign?categories=All). It does seem that the status is "Maintained" and that the only "new development" is related to my work on "cosign_auth" (Maybe I should have named it "cosso_auth" ...)
Comment #25
klausiClosing due to lack of activity. Feel free to reopen if you are still working on this application.