Bug #26910

forgot does not work with more than one login form on one page

Added by Felix Nagel over 7 years ago. Updated about 3 years ago.

Status:
New
Priority:
Could have
Assignee:
-
Category:
felogin
Target version:
-
Start date:
2011-05-19
Due date:
% Done:

0%

TYPO3 Version:
4.4
PHP Version:
Tags:
Complexity:
hard
Is Regression:
No
Sprint Focus:

Description

When using more than one login form on a page the login forgot form does not work. No email is sent. The problem seems to be the twice generated forgot hash.

This problem is verfified in TYPO3 v4.4.7 but seems to be a problem in v4.5.2 too!


Related issues

Related to TYPO3 Core - Feature #34597: Disable forgot password forms Closed 2012-03-06
Related to TYPO3 Core - Bug #64626: Rewrite fe_login to Fluid Rejected 2015-01-30
Related to TYPO3 Core - Feature #29565: It is not possible to force felogin into a certain display mode New 2011-09-08
Related to TYPO3 Core - Feature #38844: Add code list to felogin Under Review 2012-07-10
Related to TYPO3 Core - Epic #84262: [FEATURE] New sysextension feloginform Under Review 2012-07-10

History

#1 Updated by Andreas Wolf over 7 years ago

  • Status changed from New to Accepted
  • Complexity set to easy

I guess it would help to add the uid of the content element somewhere - because that will differ even for two elements on the same page.

Could you try that and maybe provide a patch?

#2 Updated by Jigal van Hemert almost 7 years ago

  • Status changed from Accepted to Needs Feedback
This is caused by two problems:
  1. pi_base plugins have no way to distinguish between two instances on the same page
  2. felogin uses a small hash which is stored in the FE user session to make sure the mail is sent to the user who requested the form

Only the hash of the last form is stored (it overwrites the others), which means that only the last form on a page has any chance of working to set a new password.

It could be solved by making the prefixId (which is present in all pi_base extensions) configurable and using that too when storing the hash, but that could lead to problems if multiple instances are used with different access settings which should work together.

I doubt that this is worth the trouble. Maybe we should just document that only one instance per page should be used?

#3 Updated by Markus Klein almost 7 years ago

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?

#4 Updated by Thorsten Kahler almost 7 years ago

  • Priority changed from Must have to Could have

Jigal van Hemert wrote:

I doubt that this is worth the trouble. Maybe we should just document that only one instance per page should be used?

+1

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.

#5 Updated by Felix Nagel almost 7 years ago

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.

#6 Updated by Thorsten Kahler almost 7 years ago

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.

#7 Updated by Felix Nagel almost 7 years ago

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.

#8 Updated by Alexander Opitz over 5 years ago

  • Status changed from Needs Feedback to New

#9 Updated by Mathias Schreiber about 4 years ago

  • Target version set to 7.2 (Frontend)
  • Complexity changed from easy to hard
  • Is Regression set to No

#10 Updated by Benni Mack over 3 years ago

  • Target version changed from 7.2 (Frontend) to 7.4 (Backend)

#11 Updated by Susanne Moog over 3 years ago

  • Target version changed from 7.4 (Backend) to 7.5

#12 Updated by Benni Mack over 3 years ago

  • Target version changed from 7.5 to 7 LTS

#13 Updated by Mathias Schreiber about 3 years ago

  • Target version deleted (7 LTS)

#14 Updated by Mona Muzaffar almost 2 years ago

#15 Updated by Georg Ringer 10 months ago

  • Related to Epic #84262: [FEATURE] New sysextension feloginform added

Also available in: Atom PDF