У меня проблемы с развертыванием Testlink на клиентском сервере. Похоже, причина проблемы в том, что это не сохранение / получение информации в сессии правильно, и это вызывает ошибки во время установки и попытки регистрации.
Во время установки переменная сохраняется в сессии (installationType) указание, является ли это новой установкой или обновлением. Эта переменная принимает значение «new», но при переходе с одного экрана на другой это значение теряется, предположим, что я выполняю обновление, и продолжить невозможно. В качестве обходного пути я внес изменения в код, чтобы установить для этой переменной значение «новое» на каждом экране, и таким образом я правильно завершил процесс установки. Но когда я пытаюсь войти, я нахожу другую проблему: после ввода пользовательских данных и доступа, экран обновится и снова отобразит экран входа без каких-либо сообщений об ошибках (на самом деле журнал показывает, что вход был успешным). Это поведение аналогично отключению файлов cookie в браузере.
Та же версия Testlink (1.9.14) была установлена без проблем на локальный сервер с идентичной конфигурацией:
- Ubuntu: 14.04.1 (64 бит)
- Apache: 2.4.7
- PHP 5.5.9-1ubuntu4.16
- MySQL: 5.5.49
Разница в том, что наша Ubuntu смонтирована на виртуальной машине в Debian, а клиент Ubuntu развернут в Azure.
Я сравнил конфигурацию php.ini на одной машине и другой, и я не нашел существенных различий. Сравнивая информацию, отображаемую phpinfo (), я также не нашел ничего релевантного (мог бы присоединить оба здесь, если это необходимо), но я вижу, что в разделе «Переменные PHP» локального сервера у меня есть этот файл cookie:
COOKIE [«TESTLINKUSERAUTHCOOKIE»]
Этот файл cookie не отображается на клиентском сервере (я полагаю, он не создается после входа в систему).
Я предполагаю, что в панели администрирования Azure (к которой у меня нет доступа) нужно что-то настроить, так же, как и открытие порта, как в iptables, так и в Azure.
Любое предложение будет с благодарностью.
Тайна разгадана. Проблема связана не с Azure, а с собственной конфигурацией сервера.
После сравнения всех файлов конфигурации Apache и PHP с новой установкой я обнаружил, что:
/ и т.д. / apache2 / сайты с поддержкой /000-default.conf
<IfModule mod_headers.c>
Header set X-UA-Compatible "IE=edge"Header set X-Frame-Options "DENY"# Commented out, because fcm4 use external JavaScript
# Header set Content-Security-Policy "script-src 'self'; object-src 'self'"Header always set Strict-Transport-Security "max-age=16070400; includeSubDomains"Header set X-Content-Type-Options "nosniff"Header set X-XSS-Protection "1; mode=block"Header unset X-Powered-By
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"Header set Pragma "no-cache"Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"Header set X-Permitted-Cross-Domain-Policies "master-only"Header edit Set-Cookie ^(.*)$ "$1;HttpOnly;Secure"<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif|htc|ico|jpe?g|js|json(ld)?|m4[av]|manifest|map|mp4|oex|og[agv]|opus|otf|pdf|png|rdf|rss|safariextz|svgz?|swf|topojson|tt[cf]|txt|vcard|vcf|vtt|webapp|web[mp]|webmanifest|woff2?|xloc|xml|xpi)$">
Header unset X-UA-Compatible
Header unset X-Frame-Options
Header unset Content-Security-Policy
Header unset X-XSS-Protection
</FilesMatch>
</IfModule>
Линии, которые вызывали это поведение, были:
После закомментировано все нормально.
Проблемы с сессиями Php обычно связаны с временными папками, используемыми Apache / Php для работы.
Я предполагаю, что Testlink реализует довольно классическую сессионную систему сессий. Следуйте этой статье, чтобы убедиться, что вы правильно настраиваете обработку сеансов.
https://support.qualityunit.com/021373-How-To-Enable-Session-Support-for-PHP
Вы также можете быть заинтересованы в этой ссылке. Это пошаговое руководство по установке Testlink на компьютере Azure:
http://thusharapriyantha.blogspot.com.es/2015/04/install-testlink-1913-stormbringer-in.html?m=1
Повезет … С наилучшими пожеланиями