TYPO3 Core

In case the plugin is inserted via the content element, we could use the uid of the CE.
If it's inserted via TS things are more complicated. Maybe a new config option to define a unique key?

Thorsten Kahler wrote:

IMHO it's nonsense and a sign of bad design (or implementation) if there are two login forms on the same page. It's easy to disable a login form from a TS template for distinct (read: forgot password) pages.

Im really interested in how to argue that two login forms are bad design. Lets say we have one login form in a mega menu and one at the login page itself. Or we have one in the footer and one at the login page. It common usage of login forms, neither bad design nor bad implementation.
But I agree if we say "it's nonsense and a sign of bad design if there are two forgot password forms on the same page".

A note in the documentation would be suitable but I would prefer if felogin just works in all circumstance without problems.

For sure its possible to fix this with TS conditions but its not only the password forgot form but all felogin forms. See #6708 and #24877 for more info.
Its a problem of the current implementation of felogin which should be fixed.

Felix Nagel wrote:

Im really interested in how to argue that two login forms are bad design. Lets say we have one login form in a mega menu and one at the login page itself. Or we have one in the footer and one at the login page. It common usage of login forms, neither bad design nor bad implementation.

How do "common usage" and "common failure" differ? Take a look at the big players (read: those who put effort into optimizing UX and security) and tell me how often you find multiple login forms on their pages.

But I agree if we say "it's nonsense and a sign of bad design if there are two forgot password forms on the same page".

That's a start :)

A note in the documentation would be suitable but I would prefer if felogin just works in all circumstance without problems.

For sure its possible to fix this with TS conditions but its not only the password forgot form but all felogin forms. See #6708 and #24877 for more info.

IMO this issue (and its duplicate) is rather an issue of RSA auth.

Its a problem of the current implementation of felogin which should be fixed.

That's just how pi_base plugins work (see Jigal's comment) - you will find problems with most of the pi_base based FE plugins, if you put multiple of them on the same page.

There's no need to use EXT:felogin for a FE login form, so why should it be implemented to fit to all imaginable kinds of usages? Btw. there are worse points in the "current implementation of felogin" which should be fixed; this one could be fixed and I see it as a (minor) feature, not a bug.

Thorsten Kahler wrote:

How do "common usage" and "common failure" differ? Take a look at the big players (read: those who put effort into optimizing UX and security) and tell me how often you find multiple login forms on their pages.

I agree but as you probably know its not always possible to convince the customer ;-)

IMO this issue (and its duplicate) is rather an issue of RSA auth.

It seems like both problems could be solved if each felogin plugin is identifiable.

That's just how pi_base plugins work (see Jigal's comment) - you will find problems with most of the pi_base based FE plugins, if you put multiple of them on the same page.

Thats correct, but almost every FE plugin with JS functionality needs a way to deal with multiple usage on one page. Why not felogin?
Markus already outlined a common solution.

this one could be fixed and I see it as a (minor) feature, not a bug.

Agree, its low priority as it could be fixed with TS (I would like to add some TS conditions to the doc).
Anyway, its a technical problem of a built in functionality so I would not consider this as a feature request.