| Author |
 Topic  |
|
bax
Junior Member
141 Posts |
 Posted - 11 August 2002 : 22:41:00
|
To those of you who have integrated Snitz with an already existing website...
We currently have a site that requires users to register, login, etc. Need to add a discussion board as part of the website, and snitz has received accolades from the client.
Our database was created over a year ago, with different field names for things like firstName, LastName, memberName, memberID, etc. At this point, I do not want to change all of our database field names to what Snitz users for their forum field names. So, a few questions...
How difficult have others found it to modify Snitz' members table to integrate with a different user table? It seems like this might make upgrading REALLY difficult, because it probably means lots of changes to db code of snitz. Or, does the new 3.4 version make it easy to specify table column names for registrants?
My thought on this is to add some sort of trigger to our database, that when users register, automatically populates the member table of the Snitz forum. Thoughts on this approach? Anyone else used this? Also, how difficult is it to add a different header to snitz in order to make the forum appear "within" our site, and to use our authentication and session persistence methods (we of course will leave all proper copyright information because you all deserve the credit for this)? |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 11 August 2002 : 22:53:06
|
quote:
Originally posted by bax
How difficult have others found it to modify Snitz' members table to integrate with a different user table? It seems like this might make upgrading REALLY difficult, because it probably means lots of changes to db code of snitz. Or, does the new 3.4 version make it easy to specify table column names for registrants?
My thought on this is to add some sort of trigger to our database, that when users register, automatically populates the member table of the Snitz forum. Thoughts on this approach? Anyone else used this?
I think the best approach would be to use Snitz member table in the way you described. It seems to be the way it is done by most of the people in your situation.
quote:
Also, how difficult is it to add a different header to snitz in order to make the forum appear "within" our site...
You'd just need to change inc_top.asp (inc_header.asp for 3.4) to do that, since it is used in all the forum's files. It will be easy to do it.
quote:
...and to use our authentication and session persistence methods (we of course will leave all proper copyright information because you all deserve the credit for this)?
I think it would be simpler to use Snitz authentication to login. It's mainly cookie based and it's pretty simple to figure out. It's also done in inc_top.asp, you can have a look. You can also have a look at inc_login.asp at Snitz Exchange, since it shows how you can login to the forum from outside the forum.
Don't know about session persistence. Can you be more specific? |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
|
bax
Junior Member
141 Posts |
Posted - 12 August 2002 : 02:39:18
|
Sure, I'll try to clarify.
1. I can't do solely cookie-based authentication. This site is designed to be used in public access situations, where I do NOT want to persist cookie information on client machine because it could potentially compromise their identity. I'll need to look at the code, but I don't want to have a situation where cookies persist.
2. When you say the "best approach" is to do what I describe, I assume you mean in terms of the database trigger?
3. Re: snitz authentication - I'll take a look at this when 3.4 is released and see what the best approach is, I guess. |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 12 August 2002 : 08:02:07
|
quote:
Originally posted by bax
Sure, I'll try to clarify.
1. I can't do solely cookie-based authentication. This site is designed to be used in public access situations, where I do NOT want to persist cookie information on client machine because it could potentially compromise their identity. I'll need to look at the code, but I don't want to have a situation where cookies persist.
Well right now it's done through cookies, or the users just need to login for each "session".
quote:
2. When you say the "best approach" is to do what I describe, I assume you mean in terms of the database trigger?
Yes.
|
Snitz 3.4 Readme | Like the support? Support Snitz too |
|
|
|
SPulley
Starting Member
USA
46 Posts |
Posted - 12 August 2002 : 19:23:38
|
In my opinion, a trigger is just one more thing to break. I went and modified all my older code to point to the Snitz users table and authenticated that way. It's worked really well.. I run a photo contest off the users table, have setup a chat program to use that table, modified pollmentor to run off the snitz users table.. My web site is totally integrated with snitz now.. I fear what 3.4 brings...
Take a look at my current site..
http://www.mylargescale.com/forum
Also to answer your question about integrating into the site design, take a look at a site that I will be launching soon. I'm very happy with the way the forums integrated into this design.
http://stage.ogaugetrains.com/forum
|
Have fun and be good!!
Shad Pulley
www.mylargescale.com/forum |
Edited by - SPulley on 12 August 2002 19:25:24 |
|
|
|
bax
Junior Member
141 Posts |
Posted - 12 August 2002 : 20:51:51
|
To SPulley:
The problem with trying to integrate with existing database is that I need several different properties about users collected than just what Snitz collects (and I also don't need a lot of what Snitz collects). It would also be much faster at this point to write a little trigger than to go back and redo a whole bunch of code to make my user table look like Snitz'.
Eventually, it would be good to do what you're saying - integrate Snitz into a more robust portal type option (such as postnuke), where it is just one of many modules. MaxWebPortal is an attempt at this, but the db design has some holes, IMO. |
|
|
|
SPulley
Starting Member
USA
46 Posts |
Posted - 13 August 2002 : 00:33:29
|
| I added the fields that I needed to the snitz user table. One place for all the needed data. |
Have fun and be good!!
Shad Pulley
www.mylargescale.com/forum |
|
|
|
Dan Martin
Average Member
USA
528 Posts |
Posted - 13 August 2002 : 02:11:23
|
On my website, I simply set up a query in the database called FORUM_MEMBERS that renames all my proprietary fields to Snitz compatible names. For Example:
SELECT PROPRIETARY_ID as MEMBER_ID ....
and so on. For fields that have no equivalent in your proprietary database, either add them, or create another table. In that table simply join on MEMBER_ID (where it's only an auto number in one of the two tables) in your FORUM_MEMBERS query.
The only downside to joining two tables is that Snitz's member deletion code will not work. You will have to edit the member deletion to delete individually from each table. Everything else will work fine. If you don't require a join, everything including the delete will work fine.
I've been running successfully like this for 2 years now. It's even made the transition between versions of Snitz. |
|
|
|
bax
Junior Member
141 Posts |
Posted - 13 August 2002 : 03:55:44
|
Dan:
Smart idea - you just created forum_members as a view, then. Did you then add stuff like Last_Post, Last_Visit for users into your proprietary table? Was there any weird stuff that had to happen for db inserts when users post? |
|
|
|
Dan Martin
Average Member
USA
528 Posts |
Posted - 14 August 2002 : 18:07:18
|
Bax, I did get your email - but I can't reply until I get home from work.
There were some oddities. Mainly - all "Date" fields get run through Snitz's chkDate function (found in inc_functions.asp) at some point or another. That function doesn't like Nulls  . It's been a while, but I think that's really the only thing I had to fix.
Of course, your mileage may vary. |
|
|
|
Dan Martin
Average Member
USA
528 Posts |
Posted - 14 August 2002 : 18:10:14
|
Oh, I should mention that the reason you'll run into nulls is because you probably don't have "Member Since" or "Last Post" values in your proprietary database for every member.
Of course, you could set them all to one specific date to start out with, and avoid that issue. |
|
|
|
rgarg
Starting Member
30 Posts |
Posted - 15 August 2002 : 16:54:16
|
Hi,
I am working on a project that has a similar situation like described here. We have our own database (Access), with it's own tables and fields for some years now. We want to integerate snitz forum with our website and then we may need to write some kind of trigger to pump values from current tables to snitz tables.
Thanks for the info. |
|
|
|
bax
Junior Member
141 Posts |
Posted - 15 August 2002 : 20:05:37
|
rgarg:
Dan's method sounds the best to me - basically, you create FORUM_MEMBERS as a view of your own main table, using
select MYDB_ID as MEMBER_ID
etc. etc. etc.
I intend to try this once 3.4 is released (this weekend, hopefully???). I'll try to remember to let you know how well this works - however, feel free to email me directly in case I forget.
Sincerely,
Bryan |
|
|
|
mxc369
Starting Member
41 Posts |
Posted - 16 August 2002 : 15:42:50
|
I have a question,
Say I have the Database connected via the query,
Will the forum recognize the user once they logged into my existing logins. i.e.: A site member logs into my sites existing login and clicks on the Forum link. That link takes them to the forum: will they have to login again with the same username and password or will they be recognized?
|
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
|
|
bax
Junior Member
141 Posts |
Posted - 18 August 2002 : 23:12:51
|
Dan, ruirib, et al.
This is a followup again to this topic...
Anyway, my question - there are a whole bunch of fields in snitz that I don't have in my proprietary user table (all the View Sig, AIM, Yahoo, ICQ stuff, for instance), and others I do have (gender, address information, etc). What did you do with those fields that did NOT exist in your proprietary table? Add them in? Or just create a table like FORUM_ADDITIONAL_MEMBER_INFO, and then FORUM_MEMBERS was a join view between the proprietary table and the ADDITIONAL INFO table? Just curious on other's approaches - I'd rather not go and start mucking around too much with my proprietary user table right now. I can, if that's the recommended method.
Sincerely,
Bryan |
|
|
|
Topic |
|
Topic Locked
