Major cookie issue - bounces out of app until deleted

Hi again

Self hosted, mostly working fine however completely randomly I am getting kicked out of the application and redirected to the root folder.

Site is running as follows:

https://mydomain/ninja - I can hit this url, login and do stuff as per normal. However completely randomly I will get booted out of the app and get returned to http:/mydomain - I then have to clear my cookies to be able to log back in and carry on.

Obviously a major PIA and not sure whats going on. My env file (relevant bits) is set as follows:


I don’t have any redirects setup apart from those already in the app. Not sure what else to try.

I have just tried the following:

1 Created a new user
2 Logged in as that user
3 Clicked randomly in the sidebar links (basically refreshing the page).

At a random number (between 3-20 clicks), I then get bounced out.

I have noticed three cookies are set, not sure if this is normal?

remember_user_ some random numbers/letters

Hillel - I can set you up an account if you want to see it first hand - let me know, any help mucho appreciated.

Once all this is sorted, i’ll grab the white label licence :slight_smile:


Maybe this is related, are you using the file session driver?

Not sure to be honest, i’ve not added anything apart from what the app originally needed, however it maybe installed upon the server by default. It’s running Centos7.2 if that helps.

Reading that post, it does seem possible that is the cause though.

I’m not sure, maybe try changing from file to cookie in config/session.php to see if it helps.

Nope same thing, if anything it appears to be worse now than before.

Without being able to replicate the problem myself it’s hard to know.

Can you try removing these three lines from the .env file to see it it helps.


Done that now, will see how it runs. Wondering how easy it would be to move it from the /ninja folder to the domain root, just a case of moving the files or is there anything else db wise I need to setup? Could the fact it’s in a sub folder be causing the issues or do you think it’s more stack related?

Changing the file structure shouldn’t require database changes.

This is the first time I’ve heard of this problem so it’s hard for me to say.

Still doing it and causing us a nightmare now operationally - it’s looking like we will have to move away from the product now, it’s just not working for us.

Sorry to hear you’re still having trouble.

According to the latest comment here ( updating to PHP 7 may help…

I’m pretty sure i’m already running it upon php7 - will check

We haven’t heard of this problem from other users which would leave me to believe it’s related your specific setup.

Yup I know, just no idea how to fix - deffo running php7

Any chance you’ve added var_dump (or some other from of output) in the application code, it could cause trouble with the session.

You may want to test with a clean install of the app on the same server to see if the problem persists.

Nothing like that. Just moved the app into the root of the domain and it still does it.

Interestingly it also does the same thing when not logged in i.e. just refreshing the login screen - took just over 35 refreshes but then went into the redirect spiral and requires cookies being cleared to fix.

Going to move it to another Linux box and see if it does the same there - failing that, i’m binning it.


I wasn’t aware you were seeing a ‘redirect spiral’, I thought you were just getting logged out.

One thing to try is to comment out lines 76 to 84 in app/Exceptions/Handler.php

Aye basically I get the redirected too many times message, results in needing to delete cookies which then means I need to log back in.

Still does it when I comment out that code.

The page isn’t working redirected you too many times.
Try clearing your cookies.

Is the web server configured to use the public folder as the web root or is /public in the URL?

Configured with public in the url - initially it was domain/ninja/public but also tried moving the files as discussed earlier to domain/public with the same results.

Must be an environment issue, OS is Centos 7 but strange nobody else has ever reported it - clearing the cookies allows us to use it again.