Can community be used to restrict access to certain areas of my site using the login?
CCUnet
my Christian web
CCUnet
my Christian web
Feb 14, 2003, 9:03 PM
Veteran (6956 posts)
Feb 14, 2003, 9:03 PM
Post #2 of 35
Views: 11784
I don't think it can do that. It provides a central log on, and authentication for programs registered, but it doesn't add any functionality to the logon/access routines that the programs have.
In short, it tells the program you are "enabled" but the program decides what you are allowed to see/do.
For instance, if you have editing ability for a subcategory inLinks, Community tells Links you are "logged in" then Links decides what you are allowed to do.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
In short, it tells the program you are "enabled" but the program decides what you are allowed to see/do.
For instance, if you have editing ability for a subcategory inLinks, Community tells Links you are "logged in" then Links decides what you are allowed to do.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Feb 15, 2003, 5:08 AM
User (425 posts)
Feb 15, 2003, 5:08 AM
Post #3 of 35
Views: 11801
If you're talking about using Community's user table and authentication to password protect certain static pages, that can (or will soon be able to) be done, with a little custom scripting using the Community API.
The subject was addressed here:
http://www.gossamer-threads.com/...i?post=229152#229152
Fractured Atlas :: Liberate the Artist
Services: Healthcare, Fiscal Sponsorship, Marketing, Education, The Emerging Artists Fund
The subject was addressed here:
http://www.gossamer-threads.com/...i?post=229152#229152
Fractured Atlas :: Liberate the Artist
Services: Healthcare, Fiscal Sponsorship, Marketing, Education, The Emerging Artists Fund
Feb 15, 2003, 7:16 AM
Veteran (2312 posts)
Feb 15, 2003, 7:16 AM
Post #4 of 35
Views: 11762
Since GCommunity contains the full GT module collection, theoritically you can do almost anything.
Also hennagaijin is right this subject was already mentioned, and Alex showed a short example for that task.
The thread URL is quoted by hennagaijin, in post above.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Also hennagaijin is right this subject was already mentioned, and Alex showed a short example for that task.
The thread URL is quoted by hennagaijin, in post above.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 19, 2003, 9:24 AM
Veteran (6956 posts)
Feb 19, 2003, 9:24 AM
Post #5 of 35
Views: 11750
You miss the point. And, it still "can't" be done.
Anything can be done, if you want to write the code. But, as Alex has said many, many times, and if you look at the very lean code for Community, it was never meant to do that, or anything remotely similar. Alex has even said so in another thread.
The reason is your other progams do not look to community for anything other than "log on" information. To move that out of the program, would require a significant rewrite of the application, and of Community.
I wouldn't even want to theoretically chart out the logic to move LinkSQL into community, and there is no reason to.
So, even if all the code was the same, not only the core modules, there is still no way to do this within a reasonable level of effort, or for any obvious reasons.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Anything can be done, if you want to write the code. But, as Alex has said many, many times, and if you look at the very lean code for Community, it was never meant to do that, or anything remotely similar. Alex has even said so in another thread.
The reason is your other progams do not look to community for anything other than "log on" information. To move that out of the program, would require a significant rewrite of the application, and of Community.
I wouldn't even want to theoretically chart out the logic to move LinkSQL into community, and there is no reason to.
So, even if all the code was the same, not only the core modules, there is still no way to do this within a reasonable level of effort, or for any obvious reasons.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Feb 19, 2003, 10:27 AM
Veteran (2312 posts)
Feb 19, 2003, 10:27 AM
Post #6 of 35
Views: 11741
Quote:
Anything can be done, if you want to write the code.Quote:
Community, was never meant to do that, or anything remotely similar. Alex has even said so in another thread.But probably you forgot what the original question was: "Can community be used to restrict access to certain areas of my site using the login?"
The answer is: yes, should be possible, using custom programming & one of following solutions:
1) using Alex's solution he gave in the mentioned. Then on referring pages you just link the following: <a href="/cgi-bin/community.cgi?page=/home/dir/page.html">
The /home/dir/ where protected pages are, should be within cgi-bin or protected by htaccess
2) using htaccess and 401 code. It's more complex than Alex's solution, but I always liked htaccess solutions, probably I would use this solution.
3) maybe there are other solutions, like SSI... But I don't think on it further, I'm busy now, so I don't mind about it.
Anyway, not an easy task, but there are possible solutions, as listed.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 20, 2003, 1:40 PM
Veteran (6956 posts)
Feb 20, 2003, 1:40 PM
Post #7 of 35
Views: 11681
Ouch.
What you are suggesting, is to write a community-aware password-protected directory program.
Again, I stand by the major code writing, and anything can be done if you want it badly enough.
It might be possible to take an existing htaccess/password-protect program, and move the log-on portion to community, but any "good" ones I've seen had hefty price tags.
But, again, community is not meant to manage the access, timing out, updating password files, etc. It's a process of writing a program for doing that, but passing the buck on "authentication" to community.
If you run a purely dynamic site, and use something like page.cgi to serve it up, you could probably turn Links into an "overseer" program, using community to initiate the authentication, then using Links and a plugin into page.cgi to manage user authentication to sub-sections.
It's a two-step. Authenticate with community, get authorization to run the page.cgi script/access the site, then have *that* script check your local access to the page you are requesting.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
What you are suggesting, is to write a community-aware password-protected directory program.
Again, I stand by the major code writing, and anything can be done if you want it badly enough.
It might be possible to take an existing htaccess/password-protect program, and move the log-on portion to community, but any "good" ones I've seen had hefty price tags.
But, again, community is not meant to manage the access, timing out, updating password files, etc. It's a process of writing a program for doing that, but passing the buck on "authentication" to community.
If you run a purely dynamic site, and use something like page.cgi to serve it up, you could probably turn Links into an "overseer" program, using community to initiate the authentication, then using Links and a plugin into page.cgi to manage user authentication to sub-sections.
It's a two-step. Authenticate with community, get authorization to run the page.cgi script/access the site, then have *that* script check your local access to the page you are requesting.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Feb 20, 2003, 2:33 PM
Veteran (2312 posts)
Feb 20, 2003, 2:33 PM
Post #8 of 35
Views: 11694
Pugdog,
I already posted my opinion. It's up to you, if you don't to aggree with me. I feel perharps you did not fully understood my ideas, but I'm busy now, so will not describe in details.
IMO, the subject was discussed out completely, tough no complete solution was given, just ideas.
If anybody has time to work on it, just do it...
Sorry I have no more time for that subject.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
I already posted my opinion. It's up to you, if you don't to aggree with me. I feel perharps you did not fully understood my ideas, but I'm busy now, so will not describe in details.
IMO, the subject was discussed out completely, tough no complete solution was given, just ideas.
If anybody has time to work on it, just do it...
Sorry I have no more time for that subject.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 20, 2003, 4:33 PM
Administrator (9387 posts)
Feb 20, 2003, 4:33 PM
Post #9 of 35
Views: 11730
Hi,
We are actually doing this for a client right now. I've uploaded it so people can try it out. It requires mod_perl, but it is a nice mod_perl handler so you can put:
PerlModule Community::ModPerl::Access
PerlAccessHandler Community::ModPerl::Access
PerlSetVar CommunityPrivatePath /home/alex/projects/community/private
in any .htaccess file or in any <Directory> block in httpd.conf and it will only allow people who are logged into Community to get access to those files. If you aren't logged in, it will kick you back to the login page, and once you log in, get automatically kicked back.
Did I mention GossamerHost has mod_perl servers already preconfigured to make this a snap? =)
We will look at expanding this so you can do the normal `require user` syntax to allow only ceartain Community users in.
Cheers,
Alex
--
Gossamer Threads Inc.
We are actually doing this for a client right now. I've uploaded it so people can try it out. It requires mod_perl, but it is a nice mod_perl handler so you can put:
PerlModule Community::ModPerl::Access
PerlAccessHandler Community::ModPerl::Access
PerlSetVar CommunityPrivatePath /home/alex/projects/community/private
in any .htaccess file or in any <Directory> block in httpd.conf and it will only allow people who are logged into Community to get access to those files. If you aren't logged in, it will kick you back to the login page, and once you log in, get automatically kicked back.
Did I mention GossamerHost has mod_perl servers already preconfigured to make this a snap? =)
We will look at expanding this so you can do the normal `require user` syntax to allow only ceartain Community users in.
Cheers,
Alex
--
Gossamer Threads Inc.
Attached Files:
-
Access.pm (2.95 KB)
Feb 20, 2003, 5:18 PM
Administrator (9387 posts)
Feb 20, 2003, 5:18 PM
Post #11 of 35
Views: 11678
Of course! 
Actually, this was done for a client who was turning into a member only site, and had a number of applications and a lot of content (hand done html pages grown over time, over 5,000 of them).
We simply tell Apache to use this mod_perl handler for anything in a /members/ directory, and it then only allows Community members in (by checking the cookie, not another pop up user/pass box).
I will be including it as part of Community though, as it's a pretty useful tool for those who have mod_perl available.
Cheers,
Alex
--
Gossamer Threads Inc.
Actually, this was done for a client who was turning into a member only site, and had a number of applications and a lot of content (hand done html pages grown over time, over 5,000 of them).
We simply tell Apache to use this mod_perl handler for anything in a /members/ directory, and it then only allows Community members in (by checking the cookie, not another pop up user/pass box).
I will be including it as part of Community though, as it's a pretty useful tool for those who have mod_perl available.
Cheers,
Alex
--
Gossamer Threads Inc.
Feb 22, 2003, 4:03 AM
Veteran (6956 posts)
Feb 22, 2003, 4:03 AM
Post #12 of 35
Views: 11588
<G> ok... it's pretty cute, but it's limited and not how I read the "needs" of the original question, even if you start to look at require-valid-user.
The problem is the way I read the original question, was to use GC to restrict access to different areas of the server, or existing GT program features such as editor in Links or moderator in GF.
For local reature access, this would require both the hooks (the Access.pm + upgrades to reqire valid user) AND an interface program to manage the .htpasswd file(s).
1) without require-valid-users, it's blanket access for all GC logons.
2) It's also not an easily accessible, modifiable, and tunable feature -- again, which is how I read the question -- but rather a simple low-level change to apache being filtered through an access module -- all or none.
3) it runs under mod_perl and not everyone runs mod_perl.
4) it doesn't provide management features for updating the .htpasswd files for require-valid-users
If you add the ability to "require users" you get full access screening, from the authentication end, but you would still need to have a user/.htaccess management program to add/delete/manage users -- essentially adding a plugin-application to GC to monitor.
<G>... this goes back to GC not being anything but an authentication program. It requires external applications to do the work.
Access.pm is a "key" module in getting there, and allowing basic server authentication to make use of the GC logons, but there would still be two systems -- one adding users to the .htaccess system, and GC moderating the actual access to any protected directory.
I may be reading too much into this, but server authentication is a scattered business, especially if you have more than one level of access.
It would be a *BIG* benefit if you wrote an .htpassword management program, that filtered through GC as described. You had a plugin that allowed setting up the password protected directories (each with their own password file) and an interface to add/delete/update users either manually, or by a script. ibill, ccbill, and others can modify and manage the .htpasswd files externally, and turn on/off access by subscription times. GC would then provide the user logon in cooperation with those valid-users.
But I still really see two different programs, and things going on.
1) GC authenticating a users blanket access, and/or checking for a require-valid-user status in an .htpasswd file
2) managing the .htpasswd files and user access to the site.
#1 just enhances GC's ability to be an access manager and adds the ability to do #2, if the program is written to do it.
#2 answers (in my reading of it) the original question, but is now potentially possible, if GC can also handle the require-valid-user status.
Sorry this got long, my head is spinning over a few things I'm trying to work out the logic for.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
The problem is the way I read the original question, was to use GC to restrict access to different areas of the server, or existing GT program features such as editor in Links or moderator in GF.
For local reature access, this would require both the hooks (the Access.pm + upgrades to reqire valid user) AND an interface program to manage the .htpasswd file(s).
1) without require-valid-users, it's blanket access for all GC logons.
2) It's also not an easily accessible, modifiable, and tunable feature -- again, which is how I read the question -- but rather a simple low-level change to apache being filtered through an access module -- all or none.
3) it runs under mod_perl and not everyone runs mod_perl.
4) it doesn't provide management features for updating the .htpasswd files for require-valid-users
If you add the ability to "require users" you get full access screening, from the authentication end, but you would still need to have a user/.htaccess management program to add/delete/manage users -- essentially adding a plugin-application to GC to monitor.
<G>... this goes back to GC not being anything but an authentication program. It requires external applications to do the work.
Access.pm is a "key" module in getting there, and allowing basic server authentication to make use of the GC logons, but there would still be two systems -- one adding users to the .htaccess system, and GC moderating the actual access to any protected directory.
I may be reading too much into this, but server authentication is a scattered business, especially if you have more than one level of access.
It would be a *BIG* benefit if you wrote an .htpassword management program, that filtered through GC as described. You had a plugin that allowed setting up the password protected directories (each with their own password file) and an interface to add/delete/update users either manually, or by a script. ibill, ccbill, and others can modify and manage the .htpasswd files externally, and turn on/off access by subscription times. GC would then provide the user logon in cooperation with those valid-users.
But I still really see two different programs, and things going on.
1) GC authenticating a users blanket access, and/or checking for a require-valid-user status in an .htpasswd file
2) managing the .htpasswd files and user access to the site.
#1 just enhances GC's ability to be an access manager and adds the ability to do #2, if the program is written to do it.
#2 answers (in my reading of it) the original question, but is now potentially possible, if GC can also handle the require-valid-user status.
Sorry this got long, my head is spinning over a few things I'm trying to work out the logic for.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Feb 22, 2003, 7:27 AM
Veteran (2312 posts)
Feb 22, 2003, 7:27 AM
Post #13 of 35
Views: 11626
Just a short thought. Yes, .htpassword management would be fine, but I think this is not the only (and not so easy) solution for password protecting a directory in cooperation of GCommunity user database. IMO. Personally I prefer using redirect as an easy solution.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 22, 2003, 7:50 AM
Veteran (2312 posts)
Feb 22, 2003, 7:50 AM
Post #15 of 35
Views: 11628
However I like .htaccess, I aggreed that it's reasonable to move away from .htaccess solution. The redirect solution would be easy I think. This redirects to GComm login, then read referer info, and after authorized login redirect to static page, or redirect to dynamic page.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Last edited by:
webmaster33: Feb 22, 2003, 8:23 AM
Feb 22, 2003, 9:05 AM
Veteran (6956 posts)
Feb 22, 2003, 9:05 AM
Post #16 of 35
Views: 11649
.htaccess is standard on Unix. It's also pretty standard for most existing access systems. It's the core of apache security and access. Touring SourceForge or Apache.org shows loads of modules available for all sorts of things.
The suggestion above was to get existing unix/apache security to work with GC. Since this is a mod_perl solution, we are pretty much talking apache anyway.
The real point here, is that the "solution" is still outside GC. Even with the Access.pm, all you've got is another hook for access to the authentication system. You still have to write the management system.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
The suggestion above was to get existing unix/apache security to work with GC. Since this is a mod_perl solution, we are pretty much talking apache anyway.
The real point here, is that the "solution" is still outside GC. Even with the Access.pm, all you've got is another hook for access to the authentication system. You still have to write the management system.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Feb 22, 2003, 11:22 AM
Administrator (9387 posts)
Feb 22, 2003, 11:22 AM
Post #17 of 35
Views: 11628
Hi,
First off, this is by far the only way to restrict access. This is really just like my other post and an example of using the API. The mod_perl handler is much nicer in that you can protect any section of your site without making any changes to the content in the site (no messing with URL's, etc). It does require mod_perl, so it's not for everyone.
If you look at the code, you'll see it's trivial to enhance it. You get a Community user, and can add whatever tests you want on that user to decide if they can get in, but yes, by default it's a blanket all or nothing feature.
Cheers,
Alex
--
Gossamer Threads Inc.
First off, this is by far the only way to restrict access. This is really just like my other post and an example of using the API. The mod_perl handler is much nicer in that you can protect any section of your site without making any changes to the content in the site (no messing with URL's, etc). It does require mod_perl, so it's not for everyone.
If you look at the code, you'll see it's trivial to enhance it. You get a Community user, and can add whatever tests you want on that user to decide if they can get in, but yes, by default it's a blanket all or nothing feature.
Cheers,
Alex
--
Gossamer Threads Inc.
Feb 22, 2003, 11:24 AM
Administrator (9387 posts)
Feb 22, 2003, 11:24 AM
Post #18 of 35
Views: 11609
Quote:
Personally I prefer using redirect as an easy solution.Can you explain that method a bit more?
Cheers,
Alex
--
Gossamer Threads Inc.
Feb 24, 2003, 7:52 PM
Veteran (2312 posts)
Feb 24, 2003, 7:52 PM
Post #19 of 35
Views: 11602
Re: [Alex] restrict access with community
Hi Alex,
Sorry for late reply.
I will try to describe ideas I originally wrote in This post above.
Solution: Alex, you gave the solution, no need to describe.
Advantage:
- very easy solution, needs just a new cgi script, which uses GComm functions
- works fine for static referer pages, result page is generated dynamically. On LSQL generated page, there may be problems as listed in disadvantages list.
Disadvantage:
- all URLs on the website, to protected pages needs to be changed. In LSQL automatic generation of protected URLs, would not be too easy: <a href="/cgi-bin/community.cgi?page=/pages/Computers/Accessories/index.html">
- search engines may not like these dynamic URLs (Rewrite rule may needed)
- no group level access of protected pages (e.g. member access to /members, editor access to /editors, etc.). Can be implemented, but would be better to have it implemented into core GComm code. This feature is missing from GComm, not from this solution.
using htaccess and 401 code. It's more complex than Alex's solution, but I always liked htaccess solutions, probably I would use this solution.Solution: This is the redirect solution I mentioned in previous post.
It can be solved in 2 ways:
2/a) I was wrong because 401 Basic Authorization pops up the login window, then can be redirected to error page. This is not good in this case.
Instead we can use 303 code (status 303 indicates, that the resource has been replaced).
In .htaccess we place all directories which are protected (members only) like this:
ErrorDocument 303 /cgi-bin/gcomm/protect.cgi
Redirect 303 /pages/Computers/Accessories/ http://www.site.com/cgi-bin/gcomm/protect.cgi
Redirect 303 /pages/Computers/Printers/ http://www.site.com/cgi-bin/gcomm/protect.cgi
etc...
2/b) using meta refresh (redirect) in index.html page: <meta http-equiv="refresh" content="0;url=http://www.site.com/cgi-bin/gcomm/protect.cgi">
After the redirection:
The protect.cgi script will do the following:
- take the referer URL (/pages/Computers/Accessories/)
- compare with stored member URLs. If we found that referer URLs was valid comparing to the stored URLs, then we redirect to the output URL, to display member only webpage.
We have these data stored in db or file (yes, hashed storage is possible, but this format is descriptive):
number | matching referer page | output URL, the page where we redirect after matching
1 | /pages/Computers/Accessories | /cgi-bin/page.cgi?g=Computers/Accessories&d=1
2 | /pages/Computers/Printers | /S<%SessonID%>/Computers/Printers
3 | /pages/Computers/Printers | /<%Random%>/Computers/Printers/
- 1st database record example redirects to a dynamic page
- 2nd database record example redirects to a dynamic page, and uses ReWrite rule to display the correct dynamic page. <%SessonID%> tag is replaced by user session ID. E.g.: /S8734874387/Computers/Printers/ using ReWrite rule will be used as /cgi-bin/lsql/page.cgi?g=/Computers/Printers&SID=8734874387&d=1
- 3rd database record example redirects to a static page, which is placed to a periodically generated (e.g. daily), random dirname like this: /tQhJU2jk8Hq2w/Computers/Printers/ (however solution this also needs a plugin for nph-build.cgi, IMO it's possible)
Advantage:
- possible solution for both dynamic & static pages
- original URLs are not changed, however plugin is needed for static solution (3rd example above)
- 2/b) is generally not webserver dependent. Not necessarily needs specific webserver (except if we want to use ReWrite rule)
Disadvantage:
- difficult solution
- a lot custom programming needed
- 2/a) is webserver dependent because of .htaccess usage
- 2/a) is good only for directory based redirecting (1 file/dir). If we use more files, /dir/index.html & /dir/page.html, then I bet we may experience problems. Not sure, tough.
- no group level access of protected pages (e.g. member access to /members, editor access to /editors, etc.). This feature is missing from GComm, not from this solution.
Solution: <!--#include virtual="/cgi-bin/lsql/protect.cgi" -->
Probably this is the easiest solution.
The protect.cgi script will do the following:
- take the referer URL (/pages/Computers/Accessories/)
- compare with stored member URLs. If we found that referer URLs was valid comparing to the stored URLs, then we redirect to the output URL, to display member only webpage.
...
This part is could be even same as the description after 2/b) "After the redirection" part.
However SSI is very great solution, and makes redirecting unnecessary, because can display the content in place.
So we read referer URL, match to the ones in database, and if found a matching one, we display content from file/template from URL which was attached to the matched one:
number | matching referer page | output URL of file/template
1 | /pages/Computers/Accessories | /cgi-bin/lsql/admin/templates/category.html
2 | /pages/Computers/Printers | /cgi-bin/lsql/admin/templates/category.html
3 | /pages/ | /cgi-bin/lsql/admin/templates/home.html
In protect.cgi, we do authorization check, display login if no session, and display output file/template if logged in. Templates are needed to parse.
Advantage:
- Very easy solution, needs just a new cgi script for SSI, which uses GComm functions
- Works fine for static referer pages, result page is generated dynamically. On LSQL generated page, there may be problems as listed in disadvantages list.
- clean URLs, no URL change needed (but plugin needed to change nph-build.cgi functions).
- Search engines likes this solution
- SSI is available in most webservers, gives clean solution
Disadvantage:
- SSI support is needed
- plugin likely needed to change nph-build.cgi functions
- no group level access of protected pages (e.g. member access to /members, editor access to /editors, etc.). Can be implemented, but would be better to have it implemented into core GComm code. This feature is missing from GComm, not from this solution.
I tried to create a summary of all 3 mentioned solutions, to describe them in more details, and to list advantages/disadvantages of them (IMO).
Finally I think, that 3) SSI solution would be my favourite solution.
The 2/b) solution is much difficulter to develop, but can provide more webserver independence.
There may happen, that I made some mistakes, I'm tired at that time, and have no patience to check for mistakes. Please correct me, if I wrote something wrong.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Sorry for late reply.
I will try to describe ideas I originally wrote in This post above.
Quote:
1) using Alex's solution he gave in the mentioned thread. Then on referring pages you just link the following: <a href="/cgi-bin/community.cgi?page=/home/dir/page.html">Advantage:
- very easy solution, needs just a new cgi script, which uses GComm functions
- works fine for static referer pages, result page is generated dynamically. On LSQL generated page, there may be problems as listed in disadvantages list.
Disadvantage:
- all URLs on the website, to protected pages needs to be changed. In LSQL automatic generation of protected URLs, would not be too easy: <a href="/cgi-bin/community.cgi?page=/pages/Computers/Accessories/index.html">
- search engines may not like these dynamic URLs (Rewrite rule may needed)
- no group level access of protected pages (e.g. member access to /members, editor access to /editors, etc.). Can be implemented, but would be better to have it implemented into core GComm code. This feature is missing from GComm, not from this solution.
Quote:
2) It can be solved in 2 ways:
Instead we can use 303 code (status 303 indicates, that the resource has been replaced).
In .htaccess we place all directories which are protected (members only) like this:
ErrorDocument 303 /cgi-bin/gcomm/protect.cgi
Redirect 303 /pages/Computers/Accessories/ http://www.site.com/cgi-bin/gcomm/protect.cgi
Redirect 303 /pages/Computers/Printers/ http://www.site.com/cgi-bin/gcomm/protect.cgi
etc...
After the redirection:
The protect.cgi script will do the following:
- take the referer URL (/pages/Computers/Accessories/)
- compare with stored member URLs. If we found that referer URLs was valid comparing to the stored URLs, then we redirect to the output URL, to display member only webpage.
We have these data stored in db or file (yes, hashed storage is possible, but this format is descriptive):
number | matching referer page | output URL, the page where we redirect after matching
1 | /pages/Computers/Accessories | /cgi-bin/page.cgi?g=Computers/Accessories&d=1
2 | /pages/Computers/Printers | /S<%SessonID%>/Computers/Printers
3 | /pages/Computers/Printers | /<%Random%>/Computers/Printers/
- 1st database record example redirects to a dynamic page
- 2nd database record example redirects to a dynamic page, and uses ReWrite rule to display the correct dynamic page. <%SessonID%> tag is replaced by user session ID. E.g.: /S8734874387/Computers/Printers/ using ReWrite rule will be used as /cgi-bin/lsql/page.cgi?g=/Computers/Printers&SID=8734874387&d=1
- 3rd database record example redirects to a static page, which is placed to a periodically generated (e.g. daily), random dirname like this: /tQhJU2jk8Hq2w/Computers/Printers/ (however solution this also needs a plugin for nph-build.cgi, IMO it's possible)
Advantage:
- possible solution for both dynamic & static pages
- original URLs are not changed, however plugin is needed for static solution (3rd example above)
- 2/b) is generally not webserver dependent. Not necessarily needs specific webserver (except if we want to use ReWrite rule)
Disadvantage:
- difficult solution
- a lot custom programming needed
- 2/a) is webserver dependent because of .htaccess usage
- 2/a) is good only for directory based redirecting (1 file/dir). If we use more files, /dir/index.html & /dir/page.html, then I bet we may experience problems. Not sure, tough.
- no group level access of protected pages (e.g. member access to /members, editor access to /editors, etc.). This feature is missing from GComm, not from this solution.
Quote:
3) maybe there are other solutions, like SSI... But I don't think on it further, I'm busy now, so I don't mind about it.Probably this is the easiest solution.
The protect.cgi script will do the following:
- take the referer URL (/pages/Computers/Accessories/)
- compare with stored member URLs. If we found that referer URLs was valid comparing to the stored URLs, then we redirect to the output URL, to display member only webpage.
...
This part is could be even same as the description after 2/b) "After the redirection" part.
However SSI is very great solution, and makes redirecting unnecessary, because can display the content in place.
So we read referer URL, match to the ones in database, and if found a matching one, we display content from file/template from URL which was attached to the matched one:
number | matching referer page | output URL of file/template
1 | /pages/Computers/Accessories | /cgi-bin/lsql/admin/templates/category.html
2 | /pages/Computers/Printers | /cgi-bin/lsql/admin/templates/category.html
3 | /pages/ | /cgi-bin/lsql/admin/templates/home.html
In protect.cgi, we do authorization check, display login if no session, and display output file/template if logged in. Templates are needed to parse.
Advantage:
- Very easy solution, needs just a new cgi script for SSI, which uses GComm functions
- Works fine for static referer pages, result page is generated dynamically. On LSQL generated page, there may be problems as listed in disadvantages list.
- clean URLs, no URL change needed (but plugin needed to change nph-build.cgi functions).
- Search engines likes this solution
- SSI is available in most webservers, gives clean solution
Disadvantage:
- SSI support is needed
- plugin likely needed to change nph-build.cgi functions
- no group level access of protected pages (e.g. member access to /members, editor access to /editors, etc.). Can be implemented, but would be better to have it implemented into core GComm code. This feature is missing from GComm, not from this solution.
I tried to create a summary of all 3 mentioned solutions, to describe them in more details, and to list advantages/disadvantages of them (IMO).
Finally I think, that 3) SSI solution would be my favourite solution.
The 2/b) solution is much difficulter to develop, but can provide more webserver independence.
There may happen, that I made some mistakes, I'm tired at that time, and have no patience to check for mistakes. Please correct me, if I wrote something wrong.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 25, 2003, 12:21 PM
Veteran (2312 posts)
Feb 25, 2003, 12:21 PM
Post #21 of 35
Views: 11535
Paul, if you don't like it, just ignore my post. 
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 25, 2003, 12:47 PM
Veteran (2312 posts)
Feb 25, 2003, 12:47 PM
Post #23 of 35
Views: 11488
I don't afraid that the forum will be empty, until you are here on the forum. 
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Feb 25, 2003, 3:54 PM
Administrator (9387 posts)
Feb 25, 2003, 3:54 PM
Post #24 of 35
Views: 11515
Hi,
Method 1 is easy only if you are creating content from scratch. If you have to update all the links, it's going to be quite difficult. Also: "search engines may not like these dynamic URLs (Rewrite rule may needed)" is not a disadvantadge, as this is a protected directory so search engines should not be allowed in.
I don't think Method 2 would work. You say that if a user goes to /protected/dir/ then they get redirected to protect.cgi and then redirected to page.cgi?g=dir. Well if your authorization is only in protect.cgi, what's stopping a user from bypassing that and going straight to page.cgi? You'd be much better off putting the authorization code in page.cgi, and then use rewrite to rewrite /protected/dir/ to page.cgi?g=dir.
Method 3 can be accomplished much simpler by just using method 1 and a rewrite rule:
RewriteRule /protected/(.*) /cgi-bin/protect.cgi?page=$1 [L]
and have protect.cgi authenticate the user and then output the requested html. This way you aren't maintaining a bunch of empty html pages with nothing but an ssi include in them.
Hope that makes sense,
Alex
--
Gossamer Threads Inc.
Method 1 is easy only if you are creating content from scratch. If you have to update all the links, it's going to be quite difficult. Also: "search engines may not like these dynamic URLs (Rewrite rule may needed)" is not a disadvantadge, as this is a protected directory so search engines should not be allowed in.
I don't think Method 2 would work. You say that if a user goes to /protected/dir/ then they get redirected to protect.cgi and then redirected to page.cgi?g=dir. Well if your authorization is only in protect.cgi, what's stopping a user from bypassing that and going straight to page.cgi? You'd be much better off putting the authorization code in page.cgi, and then use rewrite to rewrite /protected/dir/ to page.cgi?g=dir.
Method 3 can be accomplished much simpler by just using method 1 and a rewrite rule:
RewriteRule /protected/(.*) /cgi-bin/protect.cgi?page=$1 [L]
and have protect.cgi authenticate the user and then output the requested html. This way you aren't maintaining a bunch of empty html pages with nothing but an ssi include in them.
Hope that makes sense,
Alex
--
Gossamer Threads Inc.
Feb 25, 2003, 5:04 PM
Veteran (2312 posts)
Feb 25, 2003, 5:04 PM
Post #25 of 35
Views: 11533
Quote:
"search engines may not like these dynamic URLs (Rewrite rule may needed)" is not a disadvantadge, as this is a protected directory so search engines should not be allowed in.Quote:
I don't think Method 2 would work. You say that if a user goes to /protected/dir/ then they get redirected to protect.cgi and then redirected to page.cgi?g=dir. Well if your authorization is only in protect.cgi, what's stopping a user from bypassing that and going straight to page.cgi? You'd be much better off putting the authorization code in page.cgi, and then use rewrite to rewrite /protected/dir/ to page.cgi?g=dir.My suggested 2/b) solution avoids server dependent solutions, and the meta redirect helps us having firendly URLs when/if the user types the URL.
You are right, in 1st redirect case there is a bug, I forgot the SID parameter, which identifies the user session.
This is the correct example:
1 | /pages/Computers/Printers | /cgi-bin/lsql/page.cgi?g=/Computers/Printers&SID=8734874387&d=1
Quote:
You'd be much better off putting the authorization code in page.cgiQuote:
Method 3 can be accomplished much simpler by just using method 1 and a rewrite rule: RewriteRule /protected/(.*) /cgi-bin/protect.cgi?page=$1 [L]
and have protect.cgi authenticate the user and then output the requested html. This way you aren't maintaining a bunch of empty html pages with nothing but an ssi include in them.
Your suggested rewrite rule is really great if we use Apache. Really elegant solution.
But if we don't have Apache, the solution is to use method 3) with SSI (as long the webserver supports SSI and has enabled).
Anyway, there were several solutions listed in this thread, depending on following needs:
- Server: Apache dependent or server independent solution
- Page display method: Static or Dynamic
- URL lookout: Clean or Difficult to read
I tried to take into consideration the above listed needs, and my suggested solutions shows that diversity. Of course, knowing the exact resources we have, we can limit to the best one solution.
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...