clarification about login logic in a Webapp using Struts

[Jean Lutrin]

Hi all,

I have a question regarding how things are
named in the following scenario...

Imagine a Web site where you have to login before
you access, say, the "forums".

1. You click on the forum link
2. The server notices you're not logged yet and directs you
to the login page.
3. You enter a correct username, but you mistype your password.
4. The server ask your password a second time.
5. You enter it wrongly again.
6. The server now, after two wrong tries, propose you to send
your password back by email.
7. etc.

If we're using some kind of MVC framework (self made, or already
made, like Struts -- leaving aside consideration about wether or
not Struts is really an MVC framework etc.), what is the model,
what is the view, what is the controller in the above scenario?

I think I understand the "view" part, but what about the model
and the controller?

More specifically, there's some "logic" involved here : after two
wrong login tries, we propose to send the password back by email.
What is this logic related to?

I hope my question makes sense,

Jean



P.S: I want to precise that this is definitely not for
homework (as it seems to be a concern here Simply I want
to level my programmatic skills and my english skills.

 

[Andrew Thompson]

Imagine a Web site where you have to login before
you access, say, the "forums".

NoooOOOOooooo! Not *another* one.

[ Sorry Jean, it's an in-joke about 'web forums' that has precious
little to do with your enquiry. Hope you get an answer and that
you are not intending to use it for what I ..imagine. ;-) ]

 

[jeanlutrin]

Imagine a Web site where you have to login before
you access, say, the "forums".

NoooOOOOooooo! Not *another* one.
[ Sorry Jean, it's an in-joke about 'web forums' that has precious
little to do with your enquiry. Hope you get an answer and that
you are not intending to use it for what I ..imagine. ;-) ]

Don't worry, it made me laugh!

(btw, it's offtopic but I read many of your advices on both Java and
Javascript, including the notes about Javascript "worst" practices, keep
on the good work! Yup, sadly (I would say), as I am sometimes
developing Webapp I need to use some Javascript, when possible, to
enhance the "end user experience" )

And don't worry either, I won't use it to do "web forums" or whatever.

It's just that I need to know the correct vocabulary to discuss the
method/techniques I use with other programmers !

See you soon here or on the Javascript newsgroups (or on
the "web forums"

Jean

 

[Andrew Thompson]

...
Don't worry, it made me laugh!

(feeling guilty) But it seems to have stalled the thread, Jean!

Now come on, all you server side Guru's. Ignore my diversion to
Jean's question and muck in with a bit of guidance. (..Please?)

[ To Jean. If you cannot get any interest in this thread within
another 24 hours, I suggest you repost it as a new post and blame
me for having to do so. I promise I'll hold my tongue. ;-) ]

 

[Oscar kind]

I have a question regarding how things are
named in the following scenario...

If we're using some kind of MVC framework (self made, or already
made, like Struts -- leaving aside consideration about wether or
not Struts is really an MVC framework etc.), what is the model,
what is the view, what is the controller in the above scenario?

I think I understand the "view" part, but what about the model
and the controller?

First of all, you generally use J2EE security to authenticate a user. If
the username/password is correct, it redirects you to the page you
originally requested.

The view (as you probably guessed) is the HTML page. Yes, that's correct;
J2EE form login only needs an HTML form (JSP's are optional).

The model and controller are inplemented by the J2EE server.

More specifically, there's some "logic" involved here : after two
wrong login tries, we propose to send the password back by email.
What is this logic related to?

Alas, the various authentication frameworks are very restrictive:
- They do not provide any information as to what went wrong: you don't
know if the password is wrong, if the username doesn't exist, etc.
- They do not allow you to specify a "three strikes and you're out/..."
scenario: you don't know how many tries the user had.

For the "three strikes and you're out/..." scenario however, there is a
workaround:
- use a cookie to store the number of failed tries,
- show a different page if there are three or more failed tries, and
- modify all responses of your application to remove the cookie if needed.