Being logged out automatically / staying logged in

Help
1

Hi,

I have a script, where users can login/out.

After logging in, my users are being logged out automatically when loading another page, without any reason /
or: logging out, leaving & reloading the page, results in them being logged in again.

This is the strange thing:
I tried different domain names with this script; all having letsencrypt certificate.

This never happens with any other domain name, but the one I actually want to use.

Does anyone have the smallest idea, what this may cause?

(I installed l.e. for all domains the same way; and only one behaves like this.
The scripts code is untouched.)

I have deleted cookies for that particular domain name / tried with diff. browsers on diff. computers, always the same error.

Thank you very much.
Andy

1 Like
2

This does not sound like anything to do with the Let's Encrypt certs

Most likely related to your application. If you want us to check the certs you will need to fill out more info from the questionnaire you were shown. I looked at your history and never saw where you had completed one.

==============================================================

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

4 Likes
3

Thanks.

Sorry, but I cannot share the domain name atm.

However, somehow it is connected to that one domain name.
All others are working normal: only that one behaves like that.

(and as far as I know, the only thing connected to the domain name is the letsencrypt certificate.
Theres nothing else in the script).

1 Like
4

Can you show the script [and hide the domain with "exmaple.com"] ?

Is that site behind multiple IPs or load-balancers?

2 Likes
5

Is the script against your own system or someone elses? Many server detect bots and abandon their sessions automatically.

3 Likes
6

No,
only one IP, no load balancer.

Just very simple.

I will take a look into the cert. code / compare code of the diff. domains.

Maybe I'll find something there.

(although I already deleted old cert, installed new one, error stayed)

1 Like
7

No, nothing I know of.

1 Like
8

TLS layer is hidden from javascript (they can't get certificate of webserver it called)
browsers disable cache in non-trusted webpages though

4 Likes
9

You would really have to take a look at the source of the system you are querying to see how they vary HTTP cache headers according to cookies etc. Other factors include whether the domain has a caching proxy service as a front end, such as Cloudflare (very popular).

4 Likes
10

yes, I'm using cloudflare.

That might be the cause, somewhere.

Although, I use cloudflare for all my domains, incl. the ones which I tested; and they worked.

I will delete all now; l.e. certificate, cloudflare credentials.
Even delete nameserver for my domain etc.

After a while, will set up all again & then check.

11

Usually the cause of issues like you mentioned is when:

  • people configure or install the script incorrectly. make sure the right domains and cookie names / data are referenced.
  • there is a mismatch in cookie protocols. e.g. a cookie has a "secure" attribute for HTTPS transmission only, but users are accessing HTTP.

IMHO the easiest way to troubleshoot these issues is to monitor and analyze the request and response headers

4 Likes
12

I'd say you need to figure out the root cause of the caching issue, which is probably not really any of these and you shouldn't be deleting anything. If it's a caching issue (why do you need to script a login to your own site?) you can start by switching off the cloudflare DNS proxying (the little orange cloud icon in the DNS settings in cloudflare) which then circumvents all the fancy cloudflare tech.

Can you share the script or anything about it, such as how it maintains state and which state does it maintain?

5 Likes
13

Thanks for all your help & info.

So the following happened:

When I type in https:// domainname .com without the www., it all worked /s fine.

When I type it with www., I had the problems I described (staying logged in etc.).

Solution:

I just needed to logout of the profile using https://www. domainname .com

:upside_down_face:

Means: My browser saved the loged in status under www.

My website however is, when you click a button (link), using NO www.

So when I logged out of the profile, I always logged out without www.

(but stayed logged in under www.). - problem here is that my landing page works using www. (does not forward to https without www); thus the problems.

I will forward ANY domain query to https:// domainname .com , so no one can login via
https:// www. domainname .com

1 Like
14

Although that sounds like a valid solution to your problem; And I am glad you found it and have overcome it...
I can't help wondering: Why are those links not self-referencing?
Then anyone logging in via "www" could stay connected that way.
[and anyone not using "www" could stay conencted that way too]

3 Likes
15

yep,
investigating that atm.

Don't know; when I visit the site (no matter how I put the name in);
I am always directed to
https:// www. domainname .com [will have to change the .htaccess file:
How to remove www from your URL • Yoast ]

When I then click anything on the site, the domain will forward the domain name internal (without www).

I am using cloudflare and set up the SSL / l.e. certificate for both (with and without www).

17

Then those links must be hard-coded with that FQDN in the URL.
Thus, why I asked:

In case you are not familiar:

Fully refferenced link:
<a href="https://FQDN/path/file">link</a>

Self refferenced link:
<a href="/path/file">link</a>

So, you simply need to look for "://" OR that "FQDN" in your html code and update it where needed.

3 Likes
18

Yes, I have self referenced links all over the place.

But however managed to get logged in under https://www

Thanks

1 Like
19

Standardizing everything to work on a single correct domain is the best option, but you may get a temporary fix by configuring cookies to work across base and subdomains.

4 Likes
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.