Forum OpenACS Q&A: Protecting subsite with password

Posted by Hérick Moniz on 01/30/04 02:51 PM

When you create a new subsite, it's possible to restrict access only to member.

What I like to do is create a module that will allow a user to became a member of a subsite if this user knows the password of the subsite. That way it will be easy to restrict access to a few people. This is not the must secure way but for thing like press release or press picture it's convient to give a simple password.

Any hints to here to start from ?

Thanks

Herick

2: Re: Protecting subsite with password (response to 1)

Posted by Chris Davies on 01/30/04 04:00 PM

I would think a simple ad_form that inserted the member into the right group would do the trick.

in the Docs, look for:

ad_form
group::add_member

Then in your subsite, make sure the permissions allow that particular group access.

3: Re: Protecting subsite with password (response to 1)

Posted by Hérick Moniz on 01/30/04 06:37 PM

I understand that but how I could incorporate this concept into the subsite admin without breaking it. If fact, if I incorporate that modification into /acs-subsite/ how can I submit so it is incorporated in the openacs-5 development ?

Before starting to add feature, what I like to know, is how do we add features to an existing module. Is it possible to create a child of a module like in object programming ?

I have read the FAQ about creating a new module with the package manager but what is the best way to modify an existing one ?

Do we have to propose the modification before doing it ? Do we have to submit it to the module creator ?

Herick

4: Re: Protecting subsite with password (response to 1)

Posted by Chris Davies on 01/30/04 09:54 PM

I'm not an expert at this, and I might have missed what you were trying to do.

My thought was:

create a .tcl/.adp (or a package) that allows a user to enter a password that would add the userid to the group allowed to access the subsite. This would require them to enter the password once, the user would be added to the group that has permissions to view that subsite. Upon subsequent logins to the site, they would still have access to the subsite.

In this case, you could write a simple package or just the .tcl and .adp file to accomplish what you want.

Since permissions seem to be handled through acs-subsite, I don't know that you would need to modify acs-subsite at all.

If you have your own .tcl/.adp pair or your own package, moving your changes to another site would be pretty easy. If it was a package, and other people needed the same capability, or you needed it on another installation, you could easily install the package from your local repository. All of this without changing any of the core code.

I don't know what the procedure is to get changes into core -- someone else would need to answer that.

5: Re: Protecting subsite with password (response to 1)

Posted by Hérick Moniz on 01/30/04 10:24 PM

In fact what I like to do is add a new Join policy for subsite "Password". With this policy an user will need to provide a password to become a member of a subsite.

It seems to me that the best place to put this modification is in the /acs-subsite/ module.

6: Re: Protecting subsite with password (response to 5)

Posted by Randy O'Meara on 01/31/04 07:08 PM

I've done something similar but I called "password" the "invitation code".

I added a table relating the code to a subsite, and modified /register/user-join to a) accept a URL var containing the code, and b) to do a db lookup to verify the code. I placed this custom version of user-join in /nregister/user-join.{tcl,adp,xql}. If the code is valid, the custom user-join adds the requesting user to a subsite group (awaiting approval). In my case, the approval is processed by a subsite admin. In your case you could just add the requestor as an approved member (depending on the subsite join policy of course) and redirect them to the requested subsite.

The reason for placing this custom user-join in /nregister instead of as a page under the subsite is to handle the case where the requesting user is not a (logged in) registered user. The Request Processor will not serve the subsite page (unless the subsite is wide open) to a non-authenticated user. DO NOT place the custom user-join page under /register as this area is handled 'specially' and the redirect to the requested page after registration will not work (involves special handling of return_url under /registration).

You could send out a mail message which contains a link (to /nregister/user-join) with the embedded URL var. This way the invitee simply follows the link to join the subsite. If the subsite requires a registered user and the requestor is not registered, the normal user registration is presented prior to allowing the request to be satisfied.

Randy