Hi!

I was wondering if there's some sort of modification or add-on i could add to our site where a Links engine is running plus some other CGI scripts (top100 ranking, banners exchange, etc....)

It would be like a universal login/password required to use any of the services... cookies driven I guess, much like Yahoo does each time you try to enter their Games or WebRing sections...

Once logged in you have full access to all the scripts including Links but if you don't fill in the login/password, you only have limited access to certain parts of the website.

Ideas?

Thanks!

Upgrade to LINKS SQL...this type of portal system is highly challenging with multiple flat files. LINKS SQL already has a very good login process, along with the ability to add features via plugins.

Yes, it would be possible to do with Links 2.0, but on a low rudimentary level...and you would be limited to a few thousand users AT MOST...depending on the traffic to your web site and number of unique users and possible "member" users, you should consider a more robust application than LINKS 2.0.

Regards,

Eliot Lee
http://anthrotech.com/

Hi!

What about creating a separate .db for the users, just to match the cookie process, then, nothing to do with which Links engine you use?

There should be a script on every "member area" page which would need to test for the cookie.

I noticed Glennu created a similar mod but just for the Admin pages.

Glenn can u help here? Other help is also welcome! ;)

Right...again, you can create a user.db file, but the fact of the matter in terms of data processing, it will be challenging with multiple flat files.

Again, look strategically at your web site's usage. If your site is visited on a limited basis (let's say 50 - 300 unique users per day), then you could get away with a flat file systems like LINKS 2.0. If you have a medium to high traffic web site, then I wouldn't even waste the time building a portal system out of flat files that would be difficult to maintain and also "relate" to each other.

Regards,

Eliot Lee
http://anthrotech.com/

Well, there is another way, as a popular bank might say.

If you can use some kind of relational database, then you could have the Username, Password and sessions run from that. As each user will have a unique ID, all you need to do is store that ID with each record they create or amend.

A simple system using MySQL/PostgreSQL will save you the expense of upgrading to LSQL 2, both in terms of money, but more importantly, time.

The flat file Links is very clunky though, so if it's going to be an essential part of a web site, you would be well advised to migrate to the SQL version.

There are probably some scripts out there which will do what you want, but they will undoubtedly require some modifications ( check out http://www.freshmeat.net , http://www.hotscripts.com ). If it's a bespoke application you're looking for, you'd be advised to contact some of the "modders" found around these boards.

Cheers,


tom

-- principal director
-- leitchy.com

Not as robust, customizable, and supportable as Links SQL.

Regards,

Eliot Lee
http://anthrotech.com/

I pretty much know what needs to be done but since Im not even a rookie at perl and just started school I will not be able to help you out at this time. What you need to do is propably create a new flat file database then have each script open the file on a form script sort of like this:

open (LOG, "password.db") or die("Could not open password file for reading: $!");
open (TEMP, ">temp.db") or die("Couldn't create temp password file: $!");
flock (TEMP, 2);
while (<LOG> ) {
chomp;
my @data = split /\|/, $_;
#password is the first feild in DB
if ($form{'password'} eg $data[0]) {
&sub_to_member_file
}


and then have a from set up like this:

if ($ENV{'REQUEST_METHOD'} eq 'GET') { $buffer = $ENV{'QUERY_STRING'}; }
else { read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); }
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($URL, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{'name'} = $value;
}

Sorry I don't have more time to explain this and don't know if it did any good but I have to be heading out for driving school or I will be late. I also propably made a couple mistakes and forgot a few things, sorry about that but I have to rush. Maybe advanced programers can correct me.
Good Luck,
Paul

Hot Web Hosting
Low cost web hosting:
http://www.thehotweb.net/webhosting

hacker,

Thanks for the code but I'm still new to PERL.


The rest,

Is it that much hard to have just a small routine on every CGI I want to add this feature to (not just Links) that would check if a cookie exist and if not, take the user to the login/registration page?

User data would be stored into a separate database, no matter if it's ASCII or MySQL, I don't care. I would just like to include a call to this login checker from any CGI I want to include the call to (either Links CGI or not).

AFAIK, this would not affect Links whatsover... I mean, I don't see the need for an upgrade 2 LinksSQL.

LMK, please.

Thanks!

Anthrorules,

Was I right when I mentioned creating a separate MySQL database of users just to monitor the cookies sessions would not have anything to do with a Links upgrade?

Tu!

Yes...although you should store "client" variables like "SessionID" (randomly created).

Regards,

Eliot Lee
http://anthrotech.com/

Huh?

Why? Where?

Tu!