Коротко — это проблема не с самим iframe или формой, а с тем, как Joomla/сервер формируют промежуточный редирект. Joomla при обработке POST делает «redirect after post» (303/301) и в одном из этих redirect-Location получается схема http, поэтому браузер переходит на незащищённый URL и возникает mixed‑content / блокировка.
Типичные причины и способы исправить
1) Посмотрите заголовок Location в 303‑ответе
- Откройте DevTools → Network, найдите запрос на /registraciya?task=registration.register и посмотрите ответ 303 — что написано в Location: абсолютный URL (http://example/registraciya) или относительный (/registraciya)?
- Если Location указывает явно http://..., то именно Joomla/сервер генерирует неправильную схему.
2) Неправильная автоматическая детекция HTTPS (особенно за прокси/балансировщиком/Cloudflare)
- Если у вас фронт‑сервер/CDN/балансировщик завершает TLS (то есть между ним и PHP сервером трафик http), то PHP/Joоmla может думать, что соединение — HTTP и генерировать http‑редиректы.
- Решение: настроить передачу информации о протоколе (X-Forwarded-Proto или X-Forwarded‑SSL) от обратного прокси и/или заставить PHP считать HTTPS=on.
- Apache (в конфиге vhost или .htaccess, если разрешено):
SetEnvIf X-Forwarded-Proto "https" HTTPS=on
- Nginx (в блоке proxy / fastcgi):
fastcgi_param HTTPS on; # при условии проверки $http_x_forwarded_proto == "https"
или
if ($http_x_forwarded_proto = "https") { set $fastcgi_https "on"; }
fastcgi_param HTTPS $fastcgi_https;
- Для Cloudflare: убедитесь, что X‑Forwarded‑Proto присутствует и что режим SSL настроен корректно (Full/Full strict).
3) Проверьте configuration.php — параметр $live_site
- Если в configuration.php указано что‑то вроде public $live_site = 'http://example.com'; — Joomla будет использовать это при генерации редиректов.
- Либо оставьте пустым (''), либо укажите 'https://example.com'. Пример:
public $live_site = 'https://example.com';
Но лучше сначала попытаться настроить корректное определение HTTPS, и только при необходимости задать $live_site.
4) Force SSL и плагин/настройки Joomla
- Вы сказали, что SSL включён для frontend и admin — это хорошо. Но это не всегда влияет на Location редиректа, если PHP считает соединение http.
- Проверьте сторонние плагины/системные плагины, которые могут перехватывать регистрацию и делать редиректы.
5) Двойные редиректы (без/с косой чертой)
- Редирект с registraciya → /registraciya/ (301) — это просто поведение роутинга/SEF (добавление слэша). Но цепочка 303 (https → http) затем 301 (http → https) говорит о том, что где‑то посередине схема теряется. Устранение первой «неправильной» схемы решит проблему.
6) Быстрая «практическая» проверка
- В DevTools посмотрите цепочку редиректов и источник (IP/Server) для каждого шага.
- Если 303 отдаёт Joomla и Location содержит http, сначала попробуйте:
- временно в configuration.php выставить public $live_site = 'https://ваш_домен';
- настроить прокси‑заголовки как в пункте 2.
- После исправления перезапустите веб‑сервер и очистите кеш Joomla.
7) Рекомендация по архитектуре модалки/iframe
- Лучше загружать форму регистрации в модальном окне через AJAX (контент того же домена/протокола), а не через iframe, чтобы избежать дополнительных проблем с политиками браузера и mixed‑content. Если iframe нужен — убедитесь, что и родительская страница, и контент iframe всегда обслуживаются одним и тем же https.
Итог
Самая вероятная причина — сервер/прокси не передаёт Joomla, что запрос был через HTTPS, или в configuration.php прописан http в $live_site. Проверьте заголовок Location в 303, настройте X-Forwarded-Proto/HTTPS=on на сервере или исправьте $live_site — тогда редирект будет сразу на https и mixed content пропадёт.
Если хотите, пришлите:
- точные заголовки 303‑ответа (особенно Location),
- содержимое строки public $live_site в configuration.php,
- используете ли вы прокси/CDN (Cloudflare, AWS ELB, nginx как reverse proxy).
С этими данными дам конкретные команды/строки конфигурации для вашего сервера.