Gossamer Forum
Quote Reply
Update..
Hi,

I'll be posting a release candidate tommorrow afternoon. This is pretty much a final version, however there are a number of changes in the code that I'd like a few people to try it out to make sure we didn't miss anything. =) The final will come a day or two later.

I'm just cleaning up the Authentication and will have an Auth_WWWThreads plugin available for people tommorrow as well.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Update.. In reply to
Will the Auth_WWWThreads be available for the w3tphp version? or just the perl? I can't wait... yum!

Quote Reply
Re: Update.. In reply to
I don't have the PHP version, but I assume the underlying mysql tables are the same, so it should work just fine.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Update.. In reply to
I think the shared cooperation you are having with Scream (Rick Baker) is terrific. You both have exceptional products, and I think they work well together. It’s nice to see this interaction in today’s world. You are an inspiration, and roll model… Wink

Quote Reply
Re: Update.. In reply to
The two versions supposedly run off the same database... (as set up on wwwthreads.com)

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ


Quote Reply
Re: Update.. In reply to
i hope a vbulletin one follows... :)

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Update.. In reply to
Hello,

I too would be very interested in a vBulletin plugin as well.

P a i n t b a l l C i t y . c o m
http://www.paintballcity.com
Quote Reply
Re: Update.. In reply to
for vb2.0 especially though, a week or so until it is ready i think.

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Update.. In reply to
Hi,

Well I just finished the WWWThreads plugin and found a lot of bugs in the process (that's the main reason I was doing and since I had a copy of WWWThreads, it was a useful exercise). =)

vBulletin should be no harder/easier. What is needed is:

1. How to get at the database connection information.
2. Layout of the users table for getting/setting the password.
3. Steps I need to take to be able to remove a user.
4. How sessions are handled (via cookies, URL based, etc).

Once I get that, it should be pretty easily done. Right now with the WWWThreads you can:

1. Users who log into Links SQL can seamlessly move to the forum without re logging in.

2. Users who log into WWWThreads can seamless move to Links SQL without relogging in.

3. If you have an account in WWWThreads, and use Links SQL, your account will automatically get setup in Links SQL.

4. If you/admin change your password in Links SQL, your forum password will automatically be changed as well.

5. Deleting a user in Links SQL will remove that user in WWWThreads.

The only drawback right now is you can't add a user from Links SQL, you need to add the user first into WWWThreads. This is preferable, as you really want one central place to signup/register, not a whole bunch of different possibilities.

Due to the problems I had doing this, I won't be able to put it out today, it will come out tommorrow.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Update.. In reply to
how are you doing it Alex? are you copying the data from the wwwthreads table into the links table or are you adding columns to the wwwthreads that are needed for links sql? In otherwords, does the system end up using 1 user database or two? and if it is only 1 (wwwthreads one) how does this affect plugins, like say one that requires an extra field in user table?

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Update.. In reply to
I do not touch WWWThreads data. The data is maintained in two tables. However, WWWThreads is considered the master users table, and all user/pass lookups are done off of that table. If a user is in WWWThreads, it will get auto created the first time it is accessed in Links SQL.

Does that make sense?

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Update.. In reply to
That makes sense, the reason i ask is because i am going to be making a type of rating system for combining post counts and links submitted and wondering how i would do this, just access both different databases i see but that is fine and dosen't make much difference.

Vbulletin2.0 is all going to be done through sessions. You can choose to have the session in the url or as part of the cookie. Is this going to be a problem? also, would it work across sub-domains so can you have www.forums.domain.com and www.dir.domain.com sharing the same authentication system withour requiring a log in?

cheers alex this will make life a lot easier :)

http://www.ASciFi.com/ - The Science Fiction Portal
Quote Reply
Re: Update.. In reply to
If it's implemented in Cookies, you can't cross domains (as Links SQL won't get the cookie). URL based sessions will work fine.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: Update.. In reply to
Hello Alex!

Somehow this would be certainly great in the overall management.

But then the question is how to make it work with other scripts too, like for e.g. G-Mail or any other.

That means if there is a function or sub_routine that searches or generalizes the function and tells the script to which GROUP IT BELONGS TO that would be a long term solution.

That means if there are some fields in the same User table with the following:
GMail.....................'Yes' | 'No'
WWWThreads.........'Yes' | 'No'
Ads.......................'Yes' | 'No'
Classifieds..............'Yes' | 'No'

Lets say, GT comes up with anathor product. One simplly have to go to that Central User table and add a field. Start the field values with 'No' and then email all the users inviting them tto join, User validates, and the field value is changed to 'Yes'. This would be in the Central user database. For instance, I am using Links SQL and would like to invite registered users to use GMail then I simply could use a central User database and get it going.

I would not even mind a week more of a delay in comparision to what the GROUP IT BELONGS TO functionality can bring into. It is really a headache to install, work with all kinds of setup problems and then get things going. A delay of a week, even though it upsets many, would save lots of energy of many others.

What I would like to see is that atleast the products/scripts (Links SQL and GMail) should work harmoniously working togather, which is not the case unfortunately. This is not a critisism, pl. do not misunderstand, but a simply request, and we all know that this is due to a cronological development of products. I would like to see a plug-in for Gossamer Mail and WWWThreads. Make sense!!!



Quote Reply
Re: Update.. In reply to
One suggestion I gave about three months ago was to create two additional tables:

1)Status - contains all the permissions/user status information with the following fields:

ID
Status (administator, moderator, editor, power user, registered, banned)

2) User_Status - contains multiple records for each user (N->M connection):

ID
UserID
StatusID

This would allow users to have multiple statuses and be able to do multiple things in your scripts based on their status.

I do have this working (at least on the back-end)...I am still tweaking the front-end login process. But of course, I am still using Links SQL v.1.13, since it really addresses all my needs at this point. I don't anticipate upgrading to NG until probably Summer 2001 or Winter 2002.

Regards,

Eliot Lee