Hi Steve, and Dan, Potentially yes, if the Domain address has not actually changed - just the SiteID argument.
I've built a similar system to what Dan is describing, and the trick to get around this potential security risk, is not to be dependant on the SiteID as an argument (POST or Search) beyond successfully logging on. The SiteID argument is obviously required to help the User be identified during the Logon process, but once autheniticated, then assign the SiteID as a User Scope Variable and always have your code use that value - never the argument one. Or for that matter, assign the User Scope variable the first time the SiteID argument is encountered. Which also means don't re-assign the User Variable if it already has a value. It shouldn't be any different than any other secure application you write. For example, you should never have a User's unique identifier as part of a URL. Any User centric data (i.e., personal) should always be stored as User Scope variables, otherwise, after I logon I could just change my ID in the address bar of my browser and start surfing as the CEO (if I knew their ID). Hope this makes sense, and that it helps a bit. Cheers...... Scott Cadillac, Witango.org - http://witango.org 403-281-6090 - [EMAIL PROTECTED] -- Information for the Witango Developer Community --------------------- XML-Extranet - http://xmlx.ca 403-281-6090 - [EMAIL PROTECTED] -- Well-formed Development (for hire) --------------------- -----Original Message----- From: "Fogelson, Steve" <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Date: Mon, 17 Nov 2003 15:26:41 -0600 Subject: RE: Witango-Talk: Multiple DB vs. Site ID > I have a question about either method. Would it be possible to login > under > on site. Manually change the siteid in the url and then be surfing > another > site (logged in)? If so, are there any security issues with this? What > would > happen to the session id? > > Thanks > > Steve Fogelson > Internet Commerce Solutions > > -----Original Message----- > From: Robert Shubert [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 3:19 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Multiple DB vs. Site ID > > > One database with a site_id is best for a hosting environment, each db > connection requires overhead. However, I would suggest that you do > both, > as this would gain your portability as well. > > Robert > > -----Original Message----- > From: Dan Stein [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 3:45 PM > To: [EMAIL PROTECTED] > Subject: Witango-Talk: Multiple DB vs. Site ID > > I am in the process of rebuilding an application so it can be resold to > customers. > > In some cases customers will elect to have me manage the hosting which > I > will be contracting out. > > I could build one database and manage the data with one set of taf > files > and > then pull data based on the site ID ( I expect this all to be > relatively > low > volume sites with periodic burst of users but averaging 1000 to 5,000 > members per customer. > > Or would it make more sense to create a new database for each customer > and > build the taf files so they were dynamic in terms of what database they > hit > and what look and feel they loaded. > > Seems like the later is best to me. I'm wondering what the list thinks. > > Dan > > -- > Dan Stein > Digital Software Solutions > 799 Evergreen Circle > Telford PA 18969 > Land: 215-799-0192 > Mobile: 610-256-2843 > Fax 413-410-9682 > FMP, WiTango, EDI,SQL 2000 > [EMAIL PROTECTED] > www.dss-db.com > > > "When you are born, you cry and those who love you rejoice. And if > you > live your life as you should, when you die, you rejoice and those who > love you cry." > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
