tracking logins

Discussion in 'Java' started by Roedy Green, Jan 28, 2009.

  1. Roedy Green

    Roedy Green Guest

    What schemes have you seen/conceived of for a server to keep track of
    which login session a client is?

    1. have the client send in a cookie containing the session id with
    each request.

    2. keep a TCP/IP stream open.

    3. allow only one session per IP, and track IP.


    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Jan 28, 2009
    #1
    1. Advertising

  2. Roedy Green

    Arne Vajhøj Guest

    Roedy Green wrote:
    > What schemes have you seen/conceived of for a server to keep track of
    > which login session a client is?
    >
    > 1. have the client send in a cookie containing the session id with
    > each request.
    >
    > 2. keep a TCP/IP stream open.
    >
    > 3. allow only one session per IP, and track IP.


    For a web app the web container maintains session via
    cookies or URL rewriting without any user code.

    For a traditional fat client - server daemon context
    a permanent socket seems as the most obvious.

    Arne

    PS: IP check is not good because multiple valid users can be
    sitting behind the same NAT firewall.
    Arne Vajhøj, Jan 28, 2009
    #2
    1. Advertising

  3. Roedy Green

    Mark Space Guest

    Roedy Green wrote:
    > What schemes have you seen/conceived of for a server to keep track of
    > which login session a client is?
    >
    > 1. have the client send in a cookie containing the session id with
    > each request.


    Good.

    >
    > 2. keep a TCP/IP stream open.


    Will be annoying for users on poor connections, since each time they
    loose a connection they'll have to log-in again.


    >
    > 3. allow only one session per IP, and track IP.


    As Arne pointed out, almost all forms of gateways and routers in popular
    use will break this. They all re-use one IP address for a group of
    client machines. Only source port+IP address is guaranteed to be
    unique. Also, one client can attach multiple times on a different
    socket and will use the same IP address. This could create concurrency
    problems for your app if you don't handle this carefully.
    Mark Space, Jan 28, 2009
    #3
  4. Roedy Green

    Guest

    On Jan 28, 1:36 am, Arne Vajhøj <> wrote:
    > Roedy Green wrote:

    ....
    > PS: IP check is not good because multiple valid users can be
    > sitting behind the same NAT firewall.


    Indeed!

    An for Webapps it's even worse than that. One session per IP not
    only fails for the reason you mentionned, but it will also fail
    because it's also perfectly valid (and very common --anyone
    monitoring successful websites has encountered that), to have
    different requests --even for elements on a same webpage-- coming
    from different IPs for a single user.

    You may even have all GET requests coming from one IP and all
    POST requests coming from another IP for a single user.

    Alex
    , Jan 28, 2009
    #4
  5. Roedy Green

    Mark Space Guest

    wrote:

    > different requests --even for elements on a same webpage-- coming
    > from different IPs for a single user.


    Are you sure about that? I've heard of different requests from the same
    user from the same IP, but not from the same user and different IPs.
    What network configuration would actually yield that type of event?

    I guess a really big NAT, with multiple machines, each with it's own IP
    address, NATing the same user through different machines... Hmmm, tricky....

    Yeah, I could see that... cookies or old single session connections it
    is then.
    Mark Space, Jan 28, 2009
    #5
  6. Roedy Green

    Guest

    On Jan 27, 8:26 pm, Roedy Green <>
    wrote:
    > What schemes have you seen/conceived of for a server to keep track of
    > which login session a client is?
    >
    > 1. have the client send in a cookie containing the session id with
    > each request.
    >
    > 2. keep a TCP/IP stream open.
    >
    > 3. allow only one session per IP, and track IP.


    4. HTTP auth, which sends credentials or a token with every request.
    It's similar to 1, but implemented differently.

    -p
    , Jan 28, 2009
    #6
  7. Roedy Green

    Guest

    On Jan 28, 9:35 am, wrote:
    > On Jan 27, 8:26 pm, Roedy Green <>
    > wrote:
    >
    > > What schemes have you seen/conceived of for a server to keep track of
    > > which login session a client is?

    >
    > > 1. have the client send in a cookie containing the session id with
    > > each request.

    >
    > > 2. keep a TCP/IP stream open.

    >
    > > 3. allow only one session per IP, and track IP.

    >
    > 4. HTTP auth, which sends credentials or a token with every request.
    > It's similar to 1, but implemented differently.
    >
    > -p


    Hello...

    I would like to ask you a simple question.

    I have this problem. One guy has been hecked my account twice from
    now. I know he is going to be coming back. I had my account back
    because my other friends scolded him and told him to give me back my
    password. I am getting frustrated a lot. I do not wish to encounter
    this problem again. I made the most strongest passwords ( believe me
    I'm good at creating strong passwords). I made the security questions
    for password. He is like programmer.. who knows how to heck people
    accounts. And I need a professional help to make sure, he won't do
    this again. How can I do it? How should I report this person to google
    company? Is there any better way?
    My gmail accounts are very personal. He keeps bothering me a lot.
    Please help me.

    If this isn't the question you should be answering, where should I ask
    this question?
    Please help

    Thanks a lot
    , Jan 28, 2009
    #7
  8. Roedy Green

    Arne Vajhøj Guest

    wrote:
    > I have this problem. One guy has been hecked my account twice from
    > now. I know he is going to be coming back. I had my account back
    > because my other friends scolded him and told him to give me back my
    > password. I am getting frustrated a lot. I do not wish to encounter
    > this problem again. I made the most strongest passwords ( believe me
    > I'm good at creating strong passwords). I made the security questions
    > for password. He is like programmer.. who knows how to heck people
    > accounts. And I need a professional help to make sure, he won't do
    > this again. How can I do it? How should I report this person to google
    > company? Is there any better way?
    > My gmail accounts are very personal. He keeps bothering me a lot.
    > Please help me.
    >
    > If this isn't the question you should be answering, where should I ask
    > this question?


    Unless the web app in question is coded in Java and you have
    access to change the code in the web app, then this is not
    the right forum.

    Arne
    Arne Vajhøj, Jan 28, 2009
    #8
  9. Roedy Green

    Roedy Green Guest

    On Wed, 28 Jan 2009 11:06:16 -0800 (PST), wrote,
    quoted or indirectly quoted someone who said :

    >I have this problem. One guy has been hecked my account twice from
    >now. I know he is going to be coming back. I had my account back
    >because my other friends scolded him and told him to give me back my
    >password. I am getting frustrated a lot. I do not wish to encounter
    >this problem again. I made the most strongest passwords ( believe me
    >I'm good at creating strong passwords). I made the security questions
    >for password. He is like programmer.. who knows how to heck people
    >accounts. And I need a professional help to make sure, he won't do
    >this again. How can I do it? How should I report this person to google
    >company? Is there any better way?
    >My gmail accounts are very personal. He keeps bothering me a lot.
    >Please help me.


    If he is guessing your password, try using an 8-char password created
    by this program http://mindprod.com/applet/password.html

    If he is hacking into the server, that is the problem of whomever
    manages the server. Tell them what is happening and ask them to apply
    whatever security patches there are for their OS.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Jan 28, 2009
    #9
  10. Roedy Green

    Roedy Green Guest

    On Tue, 27 Jan 2009 17:26:15 -0800, Roedy Green
    <> wrote, quoted or indirectly quoted
    someone who said :

    >What schemes have you seen/conceived of for a server to keep track of
    >which login session a client is?


    summarising what I have learned:

    You might wonder how after the login is complete that the server can
    tell if messages coming in from the Internet are from people who are
    already logged in. There are a number of ways of doing it. Some you
    might think would work don’t.


    1. By IP. You might think the server could just check if an IP in a
    message header was from someone logged in. This does not work because
    IPs are shared. Everyone in your home on the LAN, when the access the
    Internet comes from the same IP, the IP of your router.

    2. By TCP/IP session. You might think the server would just check that
    the message came in on the same TCP/IP session as the user logged in
    on. This won't work since you often connect with multiple sessions,
    and you would not want to have to relogin just because a session
    tanked.

    3. Basic. The server sends you id/password with every request that is
    restricted. This method is not secure since the id/password pair is in
    plain text for any snoop to see.

    4. NTLM. This is a Microsoft proprietary protocol than will only work
    with Microsoft servers and clients. I don’t know how it works. Java
    supports it.

    5. By Cookie. The server sends a cookie at login time, and the user
    includes this cookie with each message to the server. This method is
    not secure since anyone snooping can spoof the user by just copying
    the invariant cookie. Further, the client’s browser must be configured
    to accept cookies, a practice which invites all manner of malicious
    spying.

    6. By HTTP auth digest. RFC 2617 Here each incoming message is
    digitally signed in an unforgeable way. The disadvantage of this
    approach is it takes a bit more CPU time to compute the digests and
    requires the more transmission overhead. The advantage is it is the
    most secure method without resorting to a fully encrypted data stream.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Jan 28, 2009
    #10
  11. Roedy Green

    Arne Vajhøj Guest

    Roedy Green wrote:
    > On Wed, 28 Jan 2009 11:06:16 -0800 (PST), wrote,
    > quoted or indirectly quoted someone who said :
    >> I have this problem. One guy has been hecked my account twice from
    >> now. I know he is going to be coming back. I had my account back
    >> because my other friends scolded him and told him to give me back my
    >> password. I am getting frustrated a lot. I do not wish to encounter
    >> this problem again. I made the most strongest passwords ( believe me
    >> I'm good at creating strong passwords). I made the security questions
    >> for password. He is like programmer.. who knows how to heck people
    >> accounts. And I need a professional help to make sure, he won't do
    >> this again. How can I do it? How should I report this person to google
    >> company? Is there any better way?
    >> My gmail accounts are very personal. He keeps bothering me a lot.


    > If he is guessing your password, try using an 8-char password created
    > by this program http://mindprod.com/applet/password.html
    >
    > If he is hacking into the server, that is the problem of whomever
    > manages the server. Tell them what is happening and ask them to apply
    > whatever security patches there are for their OS.


    If it is pure guessing then almost any password is good enough.

    If there is a hole in the app then password does not matter.

    If he can get to the hashed password, then 8 char is too short.

    Arne
    Arne Vajhøj, Feb 2, 2009
    #11
  12. Sabine Dinis Blochberger wrote:
    > Roedy Green wrote:
    >> On Tue, 27 Jan 2009 17:26:15 -0800, Roedy Green
    >> <> wrote, quoted or indirectly quoted
    >> someone who said :
    >>> What schemes have you seen/conceived of for a server to keep track of
    >>> which login session a client is?

    >> summarising what I have learned:
    >>
    >> 3. Basic. The server sends you id/password with every request that is
    >> restricted. This method is not secure since the id/password pair is in
    >> plain text for any snoop to see.
    >>

    > This is of course not a problem when using SSL. Just to keep in mind.


    Form based login also sends username/password in clear text
    unless HTTPS (SSL) is used.

    Arne
    Arne Vajhøj, Feb 3, 2009
    #12
  13. Roedy Green

    Roedy Green Guest

    On Tue, 03 Feb 2009 09:50:01 GMT, Sabine Dinis Blochberger
    <> wrote, quoted or indirectly quoted someone who
    said :

    >Otherwise a malignent person doesn't need to snoop the user, they can
    >just snoop the data right away.


    A lot of places want you to login just to discourage hit and run
    people who leave junk messages on boards. The login means the user at
    least once accepted an email message.

    The information is not secret, just the right to post is mildly
    restricted.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Feb 3, 2009
    #13
  14. Sabine Dinis Blochberger wrote:
    > Arne Vajhøj wrote:
    >> Sabine Dinis Blochberger wrote:
    >>> Roedy Green wrote:
    >>>> On Tue, 27 Jan 2009 17:26:15 -0800, Roedy Green
    >>>> <> wrote, quoted or indirectly quoted
    >>>> someone who said :
    >>>>> What schemes have you seen/conceived of for a server to keep track of
    >>>>> which login session a client is?
    >>>> summarising what I have learned:
    >>>>
    >>>> 3. Basic. The server sends you id/password with every request that is
    >>>> restricted. This method is not secure since the id/password pair is in
    >>>> plain text for any snoop to see.
    >>>>
    >>> This is of course not a problem when using SSL. Just to keep in mind.

    >> Form based login also sends username/password in clear text
    >> unless HTTPS (SSL) is used.

    >
    > You could make the case that if a login is required, the information is
    > sensitive, so you'd have to use encryption in any case.
    >
    > Otherwise a malignent person doesn't need to snoop the user, they can
    > just snoop the data right away.


    Yes.

    Arne
    Arne Vajhøj, Feb 3, 2009
    #14
  15. Roedy Green

    Arne Vajhøj Guest

    Roedy Green wrote:
    > On Tue, 03 Feb 2009 09:50:01 GMT, Sabine Dinis Blochberger
    > <> wrote, quoted or indirectly quoted someone who
    > said :
    >> Otherwise a malignent person doesn't need to snoop the user, they can
    >> just snoop the data right away.

    >
    > A lot of places want you to login just to discourage hit and run
    > people who leave junk messages on boards. The login means the user at
    > least once accepted an email message.
    >
    > The information is not secret, just the right to post is mildly
    > restricted.


    Unfortunately many people uses the same username/passwords
    at multiple sites.

    Which gives you as a site owner a responsibility to protect
    the data (unless you very explicit inform the users that you
    do not protect their data) even if the access they grant to
    your site is unimportant.

    Arne
    Arne Vajhøj, Feb 3, 2009
    #15
  16. Roedy Green

    Roedy Green Guest

    On Tue, 03 Feb 2009 12:59:22 GMT, Sabine Dinis Blochberger
    <> wrote, quoted or indirectly quoted someone who
    said :

    >Ah I see. The confirmation per email with a link the user has to click
    >or copy into their browser really is the best way, as a case of one of
    >my friends shows - he never got the confirmation, but the website
    >considered him registered anyway, and later started charging his CC.


    I find the idea of using a credit card on the Internet insane. It is
    like giving an unknown vendor a pile of blank cheques. It is so odd
    it is still so common.

    We need ways to transfer money where vendor has to identify himself,
    and you give him one-time access to a fixed amount. Paypal is pretty
    good except that most sites don't take it.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Feb 6, 2009
    #16
  17. Roedy Green

    blue indigo Guest

    On Fri, 06 Feb 2009 00:32:14 -0800, Roedy Green wrote:

    > I find the idea of using a credit card on the Internet insane. It is
    > like giving an unknown vendor a pile of blank cheques. It is so odd
    > it is still so common.


    Likewise. All of those big data breaches in the news, with compromised
    credit card numbers and credit monitoring for the afflicted. Where's the
    sense in this? Vendors should not be receiving, let alone storing, a
    secret authentication token that can be used to impersonate one of their
    customers.

    There is no excuse for this. We've had public-key cryptography since we've
    had a public, mainstream internet and since before we've had serious
    ecommerce. We know how to design authentication schemes that don't rely on
    shared secrets, where someone can prove they know a private number without
    revealing that number, and thereby prove they are authorized to release
    funds from a particular account or whatever.

    So where is the online equivalent of the personal cheque, complete with
    unforgeable digital signature and drawn on any of a number of
    internet-savvy banks? All we have are credit card numbers, which have
    virtually no security, and such sorry excuses for "internet banks" as
    Paypal. And it shows no sign of changing anytime soon.

    I credit it to inertia. Merchant transactions have been mainly cash,
    debit, and credit from time immemorial. The former doesn't work on the net
    and the authentication for the latter involves shared secrets. This worked
    okay when vendor databases of customer credit card info consisted of big
    paper ledgers, or private computer databases with no connection to the
    internet, and there was also no real way to fraudulently use a credit card
    number without physically cloning a card, raising the bar for such misuse.

    But now that bar has been lowered since you can use just the
    number, without a physical card, to order your heart's desire from
    amazon.com and its ilk.

    > We need ways to transfer money where vendor has to identify himself,
    > and you give him one-time access to a fixed amount. Paypal is pretty
    > good except that most sites don't take it.


    Paypal is pretty awful. I agree with most of the rest, except why should
    the vendor have to identify himself? Well, I guess it depends on what you
    mean by "identify". Digital signatures on electronic "cheques" and similar
    instruments allow the possibility of vendor and buyer having pseudonymity,
    with the ability to build up a reputation for the pseudonymous identity
    but also the ability to abandon it in the future for whatever reason. Of
    course, those with little or no history would be treated with some
    suspicion, and might be asked to pay up front or put up collateral for
    some things, versus someone with an established reputation as a
    non-cheater. On the vendor side, customers might prefer to shop elsewhere
    than a vendor with no, or a bad, reputation.

    But that's as it should be. Reputation should count for more than
    marketing gloss, and maybe someday soon it will again, but it should be
    possible to start over, too.

    As for relating all of this to Java, well, Java has some nice
    cryptographic algorithms, including public-key ones, in its standard
    library, and is being used heavily server-side these days, so it's a
    natural language choice for implementing some of these futuristic new
    payment systems for the 'net.

    --
    blue indigo
    UA Telecom since 1987
    blue indigo, Feb 8, 2009
    #17
  18. Roedy Green

    Roedy Green Guest

    On Sun, 08 Feb 2009 16:24:37 -0500, blue indigo
    <> wrote,
    quoted or indirectly quoted someone who said :

    >I credit it to inertia.


    In the early days there was Digital Cash, but it died. I think the
    public did not understand what it was for.

    The big credit card companies must be losing a bundle on Internet
    fraud. It seems so peculiar they don't set up something for Internet
    use that uses public private keys/certificates. The math part I could
    cook up in a weekend.

    They are going for smart cards. These will need some sort of local
    reader to use them for Internet use. Perhaps they don't want a
    separate system only to be soon replaced.

    I agree, a digital version of a paper cheque is all that is needed.
    It identifies payer, payee, amount, currency, date, unique id, what
    the funds are for, bank/account holding the funds, digitally signed.

    It is worthless to a third party. It is worthless to the payee after
    cashing.

    They could be fed into the usual cheque clearing system, but more
    likely either payer or payee would send the cheque directly to the
    bank who would verity the funds, freeze the funds and digitally sign
    to that effect.

    Banks would not like the idea of instant transfer of money. They want
    to hold it for a week as it is transferred between accounts. That's
    how they make their money.

    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Feb 10, 2009
    #18
  19. On Mon, 09 Feb 2009 19:18:52 -0800, Roedy Green wrote:

    > The big credit card companies must be losing a bundle on Internet fraud.
    > It seems so peculiar they don't set up something for Internet use that
    > uses public private keys/certificates. The math part I could cook up in
    > a weekend.
    >
    > They are going for smart cards. These will need some sort of local
    > reader to use them for Internet use. Perhaps they don't want a separate
    > system only to be soon replaced.
    >

    There are a couple of variations appearing on this side of the pond, but
    they're not (yet) widespread.

    (1) At least one of the major CCs is 'doing a PayPal' by providing
    their own card detail capture page and allowing vendors to link
    to it. Sure, this is no more secure than PayPal, but it does at
    least keep card details hidden from the vendor.

    (2) Some of the banks are issuing an offline reader for smartcards.
    It looks like a small calculator for doing three factor
    authentication. The factors are having the card, knowing the
    PIN and entering a one-time challenge value generated by the
    card issuer.

    The prompt is a web page managed by the card issuer that shows
    transaction details, asks you to use the reader and supplies
    the challenge value. You put your card in the reader and enter
    your PIN and the challenge. The reader supplies a response that
    you enter into the page and send back to the the card issuer
    for validation. The vendor presumably sends transaction details
    to the card issuer and receives a pass/fail response.

    I think this as as secure a system as I've seen to date because
    card details are never sent over the 'net. Its cheap to implement
    too, since the reader is inexpensive enough to be given away. It
    should work for all cards, since they all work in any ATM, so
    hopefully you'd not need more than one reader.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Feb 10, 2009
    #19
  20. Roedy Green

    Roedy Green Guest

    On Tue, 10 Feb 2009 13:23:53 +0000 (UTC), Martin Gregorie
    <> wrote, quoted or indirectly
    quoted someone who said :

    >(2) Some of the banks are issuing an offline reader for smartcards.
    > It looks like a small calculator for doing three factor
    > authentication. The factors are having the card, knowing the
    > PIN and entering a one-time challenge value generated by the
    > card issuer.
    >
    > The prompt is a web page managed by the card issuer that shows
    > transaction details, asks you to use the reader and supplies
    > the challenge value. You put your card in the reader and enter
    > your PIN and the challenge. The reader supplies a response that
    > you enter into the page and send back to the the card issuer
    > for validation. The vendor presumably sends transaction details
    > to the card issuer and receives a pass/fail response.
    >
    > I think this as as secure a system as I've seen to date because
    > card details are never sent over the 'net. Its cheap to implement
    > too, since the reader is inexpensive enough to be given away. It
    > should work for all cards, since they all work in any ATM, so
    > hopefully you'd not need more than one reader.



    This sounds like a proper solution. It has a big advantage. Even if
    hackers crack the OS security, they can't get hold of the private key.
    The smart card still guards. I presume the card is designed in such a
    way software CAN'T extract he private key from it.

    It seems to me though the user should not have to rekey the challenge
    phrase. Surely the credit card company must identify itself to the
    card for a challenge to even be accepted.


    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Here is a point of no return after which warming becomes unstoppable
    and we are probably going to sail right through it.
    It is the point at which anthropogenic (human-caused) warming triggers
    huge releases of carbon dioxide from warming oceans, or similar releases
    of both carbon dioxide and methane from melting permafrost, or both.
    Most climate scientists think that point lies not far beyond 2°C (4°F) C hotter."
    ~ Gwynne Dyer
    Roedy Green, Feb 15, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bill Wilson

    Forced user logins

    Bill Wilson, Jul 18, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    354
    Bill Wilson
    Jul 19, 2003
  2. Replies:
    2
    Views:
    666
    amjathrahman
    Jul 20, 2006
  3. Sameer

    preventing multiple logins

    Sameer, Oct 20, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    392
    Sameer
    Oct 20, 2003
  4. Mike Curry

    Character Recognition - Logins Etc..

    Mike Curry, Aug 4, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    445
    Mike Curry
    Aug 4, 2004
  5. Ron J
    Replies:
    3
    Views:
    619
    Ron J
    May 13, 2008
Loading...

Share This Page