[thelist] Client side vs. Server side?

Kev,

Wasabi?!  (hehe)

Stuffing all that info in your head can lead to a little confusion...
especially when the texts talk about "client-side" and "server-side"
or "validation".

There's a difference between what those terms refer to depending
on if you are dealing with a client/server architecture or the browser
as the "client" and the webserver as the "server".

Let's assume a basic setup with a single machine hosting the
database server and the webserver.  An ASP page can use 
some data access technology (like ADO) to talk to a database
server.  In this situation, the process that executes all that ASP/ADO
code is the "client" and the database management processes
are the "server".  If you read anything about cursors getting this
clear in your head will really help.  Imagine that the webserver
and the database server live on two different machines, that might
help you conceptualize the client/server relationship there a little
better (and to all you gurus out there thinking about all the (D)COM(+)
objects and marshalling processes, etc. I know, but let's not get
pedantic... :)

Okay, so that's one way of thinking about clients and servers.

Generally when people talk about "the client" in web development
we're either talking about the people we love to hate (hate to love?)
or we're talking about some web browser out their accessing pages
on our site.  In this mode of thinking the browser itself is the client
and the server is our web server running on some remote machine.

So, hopefully that helped and if you already had all that stuff pretty
straight in your head then I hope you aren't offended.

Now we can talk about validation...  Again, there is a bit of a
dichotomy when we talk about validation - there's "user validation"
and "data validation".

  We do data validation (or we should) on both
the client (web browser) and the server (web server).  We do this
so that hopefully users will only have to submit our forms once
because our client-side validation alerted them to fields that needed
mending; we never leave out server-side validation though as there
is always a possibility that our client-side stuff didn't work and/or
malicious clients are trying to send us invalid data.

  I am assuming that what you meant by "log-in validation" was
user (client) _authentication_.  There are tons of different ways to
authenticate a user, but for internet applications the most common
way is have a user supply a username and password and then 
check those values against what is stored in the database.  We
do it that way so we can track users and their habits and provide
better experiences (then there's that whole e-commerce thing).
There is no way to use javascript to _authenticate_ a user, i.e.
check their username and password.  (Well, there is, but you
would have to code those values into the page which isn't secure,
and Internet Explorer has some cool remote data access stuff
but that's not practical).

<input type="password"> has already been mentioned.

HTH.

>               I suspect that, for security reasons, doing the log-in
> validation would be best done server side, but I also intend to have a
> form
> for people to join the service so should this  be validated client or
> server
> side (I suspect this is just a matter of preference). I know enough
> JavaScript to do this client side so that won't be a problem.
>               And while I'm on the subject, does anyone have a script
> that,
> when the user types in a password, it comes up as a series of *********
> instead of their actual password?
>              Thanks in advance.
> 
> K
> kev.skindrill@bigfoot.com
> www.skindrill.freeserve.co.uk