Gossamer Forum
Home : Products : Gossamer Links : Discussions :

Separate User database

Quote Reply
Separate User database
Alex,

In looking at the Links 1.1x series, I was able to move the user database external to the local database, by checking to see if a connection had been made, if it had, dropping it, and reconnecting to the user database, then after getting the User/session info, dropping that connection and returning.

The next access by the program would create a new "local" connection, so that the connection to the database (links, categories, etc) would be what is expected.

Is this possible in the new links? I'm still trying to trace this all out.

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: Separate User database In reply to
Hi,

Yes, it's all in Links::Authenticate. Simply replace your functions with what is needed to authenticate users. You still need to maintain a users table in Links SQL, however by filling out the functions in Authenticate, it can keep them nicely synced.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Separate User database In reply to
will i be able to do something like this to mix it in with vbulletin.

I really want to merge the two user tables together, is this going to be possible do you think?

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Separate User database In reply to
Definately. What you need to do is:

1. Determine what will be the master user database. Most likely this will be vbulletin as it will be probably easier to integrate Links SQL -> vbulletin then the other way around.

2. Assuming it's Links SQL, you need to edit the Authenticate module and add code for things like:

- adding a user
- deleting a user
- checking password
- authenticate sessions

So for check password, you would add a query that would check vbulletin's user table and return 1 if it is a valid password, 0 otherwise.

It does require a little programming, but is all in one place and fairly easy to do.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Separate User database In reply to
thank you, this is very encouraging.

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Separate User database In reply to
I am almost finished modding Widgetz's forum.cgi that uses all the stuff in DBSQL and DB_Utils. It is coming along nicely...not all the features of Vbulletin, but close enough. The nice thing about Widgetz's script is that it uses internal logic of Links SQL v.1X.

Regards,

Eliot Lee
Quote Reply
Re: Separate User database In reply to
Eliot... if you ever want any help with that.

I started, but I didn't have any of the templates to go with the script, so it's sort of been on hold. I really need two sorts of "forum" scripts. A simple, lean one that can be tagged to each link to have a "discussion" about each link, and then a "general" community based board. I saw Jerry's script as a good solution for the first one, but again... I didn't have any of the supporting materials for it.

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: Separate User database In reply to
Thanks, pugdog...I may need some help at some point, but I am doing okay at this point.

Regards,

Eliot Lee
Quote Reply
Re: Separate User database In reply to
pugdog, please go for vbulletin :). It is a great script, they have a new version coming out very soon that is going to have an amazing set of features. Definitely recommended.

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Separate User database In reply to
I'm trying to stay away from PHP.

It really can't do all the things that Perl can, and perl can do all PHP can.

I've tried running PHP and mod_perl and dual servers, and all that... and I've put a lot of time into it, more than most people can afford. The end is, PHP has to take a back seat until it becomes more main-line (stable, security, supported projects either open source or commercial, etc). Right now, it's still an upstart.

PHP has a place for things like forums and maybe even shopping carts as a front end display system.

I find the code too hard to maintain (html mixed with code)

I don't like code in the HTML/document space.

I prefer a clean set of templates -- maybe with tags that expand into code or functions, but I don't want those functions _in_ the templates. This is one reason I've avoided javascript for the most part.

The difference between JS and PHP though, is JS can activate interactively on/in the browser, which makes it a useful widget for certain situations.

I'm not commenting on the qualiyt of Vbulletin. But it's the wrong language.

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: Separate User database In reply to
BTW ... PHP was a great thing for ISP's, since they can give people scripting capability without the risks of giving them shell/cgi-bin/perl access. PHP runs inside the web space, and can run from the users space. This is it's major benefit in the general web community. How far it will go depends on a lot of other factors. If you look at the development of perl, it's hard to believe PHP will develop into as robust a product, and it will probably have to lean on perl and c modules for much of the work. This is not a "bad" thing, in and of it'self. PHP was designed to do a job, and it does that. Some people want to make this a religious war like NT/Unix (heck, that's easy, one is a false god the other is real <G>) but with computer languages it's more of a matter of personal preference, and using the right language or tool for the job.

At one point I was working in about 7 different languages at one time. Each did something better/different for the purposes it was being used for. Yes, it was rough, especially back then. Now, things have settled down a bit.

I never liked SSI either. Many sites used it and still do. I think it incurs too much of a server-side penalty in performance. In some ways, PHP can, and probably will, replace that for "dynamic" pages.

But, I don't like dHTML or CCS either... partly for the same reasons.

It looks cool, it has a place, but 90% of the web can be done without it, and if that 90% didn't use it, the web would be a better place for it :)

If you try to run an interactive site (and I don't mean games, or flash, I do mean where a user searches, and selects then gets something for the effort) you'll find trying to keep up with the differences in browsers daunting enough. Throw this other stuff in, and well... it becomes more bother than it's worth.

I still believe CONTENT is king, and it always will be. If you offer something of value, you'll do well. If you just look good, you'll soon become a foot note.

I look at the phpMyAdmin program -- which was the one PHP program I did use regularly. Until MySQLMan in it's current release. With the current release, the _only_ time I load phpMyAdmin is because it has a simple one-push reload the server access (I keep forgetting to ask Alex about adding that feature). When I went through all the forum software, I went with wwwThreads because it seemed the most stable of all the products at the time.

But, it's almost a year later, my 1 year license for updates is almost up, and I'm not 100% satisfied with the program. In the past few months there have been 2 new GPL efforts on Perl bsed forums, neither of which is supportign MySQL (big mistake) and several new PHP based ones (plus the few PHP ones that have continued to develop). Maybe I'll look at them all again, since the forum software -- which is 90% display work -- is perfect for PHP.

Anyway... it's not a one or the other type deal. It's really picking the right tool for the job. Sometimes, you don't need a flat head screwdriver but a phillips. And then, sometimes neither of those works, so you pick a different option and use a hex-nut on the outside of the screw. Right tool, right job.

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: Separate User database In reply to
I understand what you say. Being someone completly new to programming, i have found PHP extremley easy to pick up use compared to cgi. The extremley easy way to access the mySQL database is especially useful and i love the way the html can be mixed in. You can, of course, use templates extremley easily much like vbulletin does where there is a template for just about everything.

And as far as forums go there seems to be little choice bar vbulletin any more. The open source options are still very much in v0.6 type stargate with phorum, yabb, boardpower, ikonboard (my favorite GPL) nice but not quite with it. WWWthreads i just really don't like, the interface is horrible although they seemed to have improved it at wwwthreads.com now. Depending on what features are needed vbulletin seems especially good, new community building features on the way (in a couple of weeks) like co-branding are for me especially useful and triple the value of the board to alternatives.

And php for me makes me able to focus on content. I can so easily write a little script that uses a database, adds to one and updates it so easily and this makes content management so easy. Doing this in cgi i think would be a lot harder (for me anyway).

So in the end i just mix and match really. Links SQL is the only product of this quality and is in cgi so go for that but vbulletin is the best and in php so i go for that but then anything i try and write will be in php i think.

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Separate User database In reply to
You've basically echoed what I said, but from the opposite side :)

As for wwwThreads, the reason it looks as it does, is if you read the developer area, is that he's rewriting it in PHP to have a PHP version.

For now, I'm staying with perl on my sites. That may change. Nothing stays the same.

What I'm really waiting for is an integration project that will put PHP as the front end to PERL. This would not be a real project in the code sense, more like a bunch of style guides and conventions, although it might spawn a php.pm type module (ala CGI.pm) to use PHP as the dynamic end for a perl/cgi generated backend rather than SSI.




PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ