Item900: FormPlugin breaks authentication system

Problem

Then a login is done, and the login form is displayed by the FormPlugin ( which i think is not a bad idea ) we get an extra redirect. The LoginManager, e.g. TemplateLogin checks for the user-data and decides, they are all wrong, so it write the login form again, using a 403.

The loginform includes %STARTFORM% etc and triggers the form plugin again, which itself recognises, hey there is some form data i need to process. ( FormPlugin.pm 395 comes into play, as the form got submitted ). So actually what it does it, again redirect the user to the /bin/login form.

1. this is useless and extra load, as the login form is showed / fetched allread
2. the 403 gets lost and e.g. ajax stuff gets broken

Possible Fix

Sol 1 ( i dont like this one )

the LoginManager could delete the form data as he processed it and decided a 403 on it. FormPlugin would not get triggered

Sol 2

Form plugin only fires the form-data transmission if we have a 403 response right now

Sol 3

we include some special cases where FormPlugin skips its own redirects

---

As part of the porting to foswiki, I think we should change the FormPlugin redirects to work like the foswiki oop's - all internally handled. FormsPlugin should throwing the appropriate exception (yes, it needs docco) and thus should not care / know how the redirect is actuated.

-- SvenDowideit - 29 Jan 2009

We got a way to restrict redirects now ( Task:Item985 )

-- EugenMayer - 05 Feb 2009

Can this item be closed then?

-- ArthurClemens - 05 Feb 2009

I dont think this adresses this issue directly. Its just a possibilty to do it on your own, but actually FormPlugin should not redirect at all. It should better load the corresponding template and show it, or run the UI::hadnleReuqeust handler with the requested action and parameters. We must get rid of this not visible "status 200" on erro redirects. -- EugenMayer - 05 Feb 2009