The action you have requested is not allowed.

robi · 2025-03-06 18:08:59

Hi

After the installation with the WebUI didn't work, I installed everything with the command line. That worked.
No, I have an issue as I cannot log in with the standard user glpi/glpi. I get this error

The action you have requested is not allowed.

System: RHEL 9.5
Webserver: Apache/2.4.62 (Red Hat Enterprise Linux)
PHP: PHP 8.3.17 (cli) (built: Feb 11 2025 22:03:03) (NTS gcc x86_64)
GLPI: 10.10.18

After checking the table entry, I saw that the users were in. At the moment, I'm out of ideas on how to solve that issue.

Thanks for your help

cconard96 · 2025-03-06 23:27:46

Please check your GLPI logs

robi · 2025-03-07 08:36:18

Good morning

This is the output of the GLPI _logs

access-errors.log

2025-03-06 15:44:52 [@pdvmtest14.profidata.com]
CSRF check failed for User ID: at /front/login.php
2025-03-06 15:59:17 [@pdvmtest14.profidata.com]
CSRF check failed for User ID: at /front/login.php
2025-03-07 06:30:34 [@pdvmtest14.profidata.com]
CSRF check failed for User ID: at /front/login.php

cron.log

Internal #1: Launch planningrecall
2025-03-06 15:52:10 [@pdvmtest14.profidata.com]
Intern #1: Starte queuednotification
2025-03-06 16:10:03 [@pdvmtest14.profidata.com]
Internal #1: Launch queuednotificationclean

php-errors.log

[2025-03-06 14:38:41] glpiphplog.WARNING: Test logger
[2025-03-06 14:43:20] glpiphplog.WARNING: Test logger
[2025-03-06 14:43:49] glpiphplog.WARNING: Test logger
[2025-03-06 15:08:03] glpiphplog.WARNING: Test logger

The php-errors.log is solved. There was a file permissions error. Cron.log is empty because there is no corn by now.
I do not understand the issue in the access-errors.log. What does that mean?

I have already used three different browsers regarding the CSRF (Cross-Site Request Forgery) Errors, and I cleared the browser cache. But I can't log in. I also have seen as the log timestamp is one hour behind the server time. Can it be that the CSFR token is not valid anymore because of a time difference?

Thanks for the help

Last edited by robi (2025-03-07 08:48:39)

cconard96 · 2025-03-07 11:40:12

Having a time difference would cause issues, although I don't know how it would affect CSRF since the expiration is only created and checked on the GLPI server side.

Try creating a "local_define.php" file in GLPI's config folder with the following contents:

<?php

if (!defined('GLPI_CSRF_EXPIRES')) {
   define('GLPI_CSRF_EXPIRES', 14400);
}

This will let CSRF tokens stay valid for 4 hours. If it works, you should check that timezones are correct on your server and GLPI.
https://glpi-install.readthedocs.io/en/ … zones.html

cconard96 · 2025-03-07 11:41:38

Also, if there were file permission errors you need to verify the other contents of GLPI's "files" folder have the correct permissions. By default, GLPI tries saving sessions in "files/_sessions" and the CSRF tokens are stored within the session files.

robi · 2025-03-07 12:22:44

I checked all permissions and ensured they were accessible from the web server. That was ok.
I also added the file you mentioned to the config folder. Unfortunately, without any success

Also, I checked the settings in the config. Everything can be read from Apache.

-rw-r--r--. 1 apache apache 353 Mar 6 15:39 config_db.php
-rw-r--r--. 1 apache apache 353 Mar 7 08:51 config_db.php_running
-rw-r--r--. 1 apache apache 32 Mar 6 16:08 glpicrypt.key
-rwxr-xr-x. 1 apache apache 115 Feb 12 11:39 .htaccess
-rw-r--r--. 1 apache apache 86 Mar 7 10:56 local_define.php

The check of the _sessions shows that the files are written into the folder.

-rw-------. 1 apache apache 1.9K Mar 7 11:01 sess_c88tjkq7j51cmp9ja073rc4jlk
-rw-------. 1 apache apache 2.2K Mar 7 11:08 sess_jgk88ce72o70h7b8ldo0u116mn
-rw-------. 1 apache apache 1.9K Mar 7 11:08 sess_nnl8e0r35l0o67n0g35uoskh8b
-rw-------. 1 apache apache 2.0K Mar 7 11:08 sess_ingr8ijui5lmmiocsokoe8ek6h
-rw-------. 1 apache apache 2.2K Mar 7 11:08 sess_81sjg9f1aqg8i80inogubbv6t7
-rw-------. 1 apache apache 1.9K Mar 7 11:08 sess_fgom8176guo3lc0nu44n85kr1m
-rw-------. 1 apache apache 2.0K Mar 7 11:18 sess_95u22frfuel06l6b4f1059anug
-rw-------. 1 apache apache 2.2K Mar 7 11:18 sess_4jovfm9bbj5tontt5k4v2b8n6s
drwxr-xr-x. 2 apache apache 4.0K Mar 7 11:18 .
-rw-------. 1 apache apache 1.9K Mar 7 11:18 sess_8df8d22vvv5psuje2nadv6fc1d

Also, the timestamp of the files is correct. But get the same error when I try to log in.

The Timezone was set during the installation, but I did a set again.

Last edited by robi (2025-03-07 12:29:44)

robi · 2025-03-07 12:33:19

If I log in, there is only the "GLP internal database" which can be selected. Is that correct?

cconard96 · 2025-03-07 13:48:53

robi wrote:

If I log in, there is only the "GLP internal database" which can be selected. Is that correct?

Yes. You don't have any external authentication sources like Active Directory configured so you can only authenticate as a user that has its password managed by GLPI.

robi · 2025-03-07 13:59:14

cconard96 wrote:

robi wrote:
If I log in, there is only the "GLP internal database" which can be selected. Is that correct?
Yes. You don't have any external authentication sources like Active Directory configured so you can only authenticate as a user that has its password managed by GLPI.

Then i have no idea wy i cant login

Forum GLPI-Project

Announcement

#1 2025-03-06 18:08:59

The action you have requested is not allowed.

#2 2025-03-06 23:27:46

Re: The action you have requested is not allowed.

#3 2025-03-07 08:36:18

Re: The action you have requested is not allowed.

#4 2025-03-07 11:40:12

Re: The action you have requested is not allowed.

#5 2025-03-07 11:41:38

Re: The action you have requested is not allowed.

#6 2025-03-07 12:22:44

Re: The action you have requested is not allowed.

#7 2025-03-07 12:33:19

Re: The action you have requested is not allowed.

#8 2025-03-07 13:48:53

Re: The action you have requested is not allowed.

#9 2025-03-07 13:59:14

Re: The action you have requested is not allowed.

Board footer