Subject | Re: [IBO] Community site should be working now |
---|---|
Author | Jason Wharton |
Post date | 2003-11-14T08:43:34Z |
> > Anyone who tried to use the community site over the past week and didn'tYes, just Indy. I dropped down a component to handle HTTP requests and built
> > have success, I have totally redone it using Indy and dumped WebBroker,
> > WebSnap and IIS6. That's why I've been a little more quiet than normal.
>
> Just Indy?
my web-site on top of that. It's really not that difficult to do if you
don't mind a little parsing and string building. It's actually quite
refreshing to get rid of IIS as well. Now you just grab an IP and a port and
start chattering.
I was also pleased to get state out of server sessions and client cookies.
That is such a pain in the butt to manage. It is so cheap and secure to put
state right in the query-line and keep session data in the database. It just
takes one stored procedure call to pass in the session idents and other
input parameters, like login requests and then to have it return the values
for the state. I have this procedure do my logging as well as generating
additional pieces of state depending on what form a user is going to. All in
one stored procedure. Fast and cheap.
I use a session id and a session fingerprint along with checking the remote
addr to make sure it is consistent. Nobody will break into someone else's
session by mistake. People will copy and paste URL's out of browsers thus
potentially sharing their state/session. That happened once to me and I saw
somone else's credit card data as a result. We do need to be careful...
The rule of thumb is, go into the webapp, take care of your business, and
for sure explicitly logout so your session will be closed and the
information it is a key to access will be removed. By this your session is
ended and no longer accessible. Using a 32 byte fingerprint and checking the
remote (client's) IP address should be a "good enough" level of security for
my app, and most anyone's.
Jason Wharton