Skip to content


login form not working #2424

sunnysideup opened this Issue · 24 comments


I am using 3.1 branches and I often get this for the login form:

Action "dologin" not allowed on form (Name: "LoginForm")

Irrespective if it is allowed or not allowed the way the error is displayed does not look profi.

can this be fixed?




url accessed is: Security/LoginForm


I've also noticed this, but also found that after a successful login, I logout, and am unable to reproduce the issue easily.

SilverStripe Ltd. member

Hi. This was raised internally too, though I have never seen it. Do you have a reliable way to replicate it?


I also note that this error isn't being picked up by the Silverstripe error logger, so I don't get an error email with stacktrace.


@tractorcow That's expected. These aren't handled by the error handler as they're not PHP errors.


Yep, I realise this is currently by design, but I do question the rationale behind the design choice.

SilverStripe Ltd. member

@sunnysideup I normally see this issue when the template in question is missing a base tag


ok, I just got it again...

I went to /admin ... and got redirected to loginform. I immediately submitted, as the details were pre-filled.



@wilr: this is more than just a template tag missing the base I believe... In fact, my template seems to have the same base tag TWICE!!!! maybe that is the problem?


here is the slightly crooked HTML:


NOTE, HOWEVER, that when I browe to /admin/ afterwards I get logged in without any problems (i.e. the login form already logged me in before!)


I can confirm that I have this problem aswell, but can't reproduce as it happens almost randomly.

After you get the error page and you browse to /admin it logs you in normally.

SilverStripe Ltd. member

Can somebody try this to reproduce. It seems to work for me:

Go to /admin
Login with the wrong details.
Login with the correct details.
Error should appear.

You can then go to /admin and you're logged in.


yes, I can replicate!


@micmania1 Tried that and I didn't get the error.


@micmania1 Like @ARNHOE, I can't reproduce with those instructions.

What about the "Remember Me" checkbox? Also, what mode is the site in? Those are the other two factors I can think of that might influence it.


We have been experiencing this intermittently on our 3.1 projects for the last few weeks now. Tried to remember what I just did the last time it happened.

I got it after I had deleted and in a Layout folder (I have created a module adminaccess for a reusable login screen), moving {$Form} into a catchall Tried to then visit /admin again, got epic errors relating to not flushing cache first. Ran /?flush=1, then tried login. Boom! Bug. Not sure if this is reproducible though.

SilverStripe Ltd. member

The problem is that Form->checkAccessAction() looks for a FormAction called login, but that's not available since for some reason the form renders as logged-in already (so there's only a FormAction called logout). I've tracked this down now that I've seen the bug for the first time on 3.1. Hadn't ticked "Remember me", and don't have a remember me token as a cookie. Can't replicate again though.

No clue on why you would already be logged in at the time of Form->checkAccessAction() - maybe a HTTP level redirect? Can somebody check the dev tools ajax responses if they can consistently reproduce this?


I am getting this, if you could run how to check the ajax responses by me I will post them here.


I also get it, only the first time I try to log in... credentials are already pre filled, no remember me token and I'm on dev mode... if I hit ( Ctrl + u ) I see I don't have head tag or body, nothing just the line that says 'Action "dologin" not allowed on form (Name: "LoginForm")'


I get this quite a lot when trying to flush on a live website.


So, this is what's happening... more or less.

The user is logged in, meaning that when the login form is generated, it generates the logout action. This means the 'dologin' action is never added, and is no longer a valid form action.

Exactly how and why it's suddenly breaking is probably due to pre-emptive logging in of the user, perhaps due to some recent security change?

I'll investigate this further tomorrow.

Also, this seems to occur when the site is in live mode.

@tractorcow tractorcow referenced this issue
Commit has since been removed from the repository and is no longer available.
@tractorcow tractorcow added a commit to tractorcow/silverstripe-framework that referenced this issue
@tractorcow tractorcow BUG Issue with login form failing to login in certain situations. Fix…
…es issue #2424

Nevermind, tomorrow can't wait.

@hafriedlander @wilr can you please review my suggested fix?

SilverStripe Ltd. member

Regardless on what causes this behaviour, I think @tractorcow has found a pragmatic fix for it. I've merged this into 3.1, and it will be part of the imminent 3.1.1

@chillu chillu closed this

@chillu @tractorcow I just experienced this problem again. I logged in with the right credentials which brought me back to the exact same login screen, when I logged in again with the right credentials I didn't get the error (as described above) and it logged me in correctly.

But something doesn't seem right yet because I get sent back to the login screen again and where usually when logging in again you got the error, it logged me in now though.


Hey @chillu

Reproduction Steps:
Branch 3.1-dev
Repro Rate: Intermittent/60-70%/Likely requires session timeout
Browser: Repro in Chrome and Firefox, cannot confirm IE

  1. Load a tab with /admin (Tab A)
  2. Load a second tab (Tab B) and log into /admin, leaving the other tab on the security login page.
  3. Leave until session timeout occurs; using incognito, private browsing or cache busters seem to reduce reproduction rate.
  4. After sometime has past go back to Tab A and attempt to log in, Tab B should still be logged in but timeout will require login.
  5. Observe Error

Notes: Interacting with the logged in (CMS) tab often reduces repro rate, you will get a growl notification saying "Not Logged in" and logging in on the other tab will work fine.

Sometimes you can get the "You are logged in as..." page in a loop, unable to log into the CMS when selecting "Log in as someone else" and entering correct details returns you to the "You are logged in as..." page.

Hope this helps.


I also had this problem with my installation in a subdirectory (/2014) when alternate_base_url was set to this subdir url in config.yml

For some reason PHPSESSID was created for both /2014/admin and /2014/Security

And the user was always presented with the "You are loggin in as..."

Hope that helps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.