чёт первый раз пожалел, что стал притягивать эвошечку 1.4 сюда

так а чем композер не угодил? секция "autoload": { "psr-4": { "App\\": "src/" } }

добавил в композере свой неймспейс и тащи всё из него

да не шарю наверное потому что

взял за базу структуру commerce

у него свой autoload.php

да и как это влияет на потерю сессии то?

Всех приветствую 👋 А есть кто-нибудь из Липецка? Хочу попробовать передать проект, который несколько туго идёт. Заказчик плохо понимает про сайты и крайне туго предоставляют информацию. Кажется если терииториально быть там, то можно сдвинуть это с мёртвой точки и закрыть проект. Готов в л/с пообщаться рассказать про бюджет и текущее состояние.

Господа, мне нужен кто-то, кто разбирается в webloginpe. Нужно добавить страницу на старый сайт. Если заинтересованы, пишите, договоримся по цене

Господа, мне нужен кто-то, кто разбирается в webloginpe. Нужно добавить страницу на старый сайт. Если заинтересованы, пишите, договоримся по цене

он глючный весь этот сниппет.

Страница должна показываться после логина пользователя и в ней должно быть показано имя клиента, остальное обычный текст

он глючный весь этот сниппет.

я не выбираю сниппет, я ищу, кто мне сделает заказ)))

я не выбираю сниппет, я ищу, кто мне сделает заказ)))

я к тому что желающих работать с этим гавном наверное не будет((

Чет да, такое себе.

йоу синьоры, кто-нибудь делал на 1.4 апишечку кроссдоменную? с введением новой политики безопасности хрома пришлось заколхозить startCMSSession() добавил 'samesite' => 'None' Но: 1. сафари похер, куку не ставит 2. в инкогнито не сохраняются куки, соответственно не могу получить сессию

я в htaccess колхозил Header edit Set-Cookie ^(.*)$ "$1; Secure; SameSite=None"

ну и Access-Control-Allow-Origin с Access-Control-Allow-Credentials проставить. везде работает вроде

а и request.setup добавить crossDomain: true, xhrFields: { withCredentials: true },

мерси попробую через htaccess withCredentials: true стоит

все условия обязательны)

Hi guys, EVO 3.1.8 has a bug. When delete a resouge with the delete button I get the error message I have no rights. This does work when delete in resource tree in the manager.

No permission 😮

все условия обязательны)

в axios не надо crossDomain: true На сервере Access-Control-Allow-Origin и Access-Control-Allow-Credentials проставлены Иначе не проходил бы даже OPTIONS браузеры не ругаются на CORS просто сафари не сохраняет куку В нормальном режиме хром и FF работают нормально В инкогнито - болт Сафари - всегда болт

хм. ну у меня к апишке коннектяцца приложухи гибридные с ios и android. все норм

надо копать

на 1,4 ?

еще раз: проблема не в CORS как таковом а невозможность получить сессию, т.к. кука с id сессии не передается

в сафари если открыть приложуху, оно тоже не сохраняет кукис. но он передаецца https://monosnap.com/direct/cVKncyTAHpsg215DAHUf7dYk2ylVJb соответственно надо искать почему сафари не юзает кукис

For Safari 11, Safari/Preferences/Privacy and uncheck Prevent cross site tracking.

))

спасибо апле за прайваси?

вероятно должен быть обходной маневр

а обходной маневр прост. браузер должен думать что он на сам себе запросы шлет. в framework7 это реализуецца прописыванием хоста равному хосту апишки

типа вот этого вероятно https://stackoverflow.com/questions/47407564/change-the-default-base-url-for-axios

еще раз: проблема не в CORS как таковом а невозможность получить сессию, т.к. кука с id сессии не передается

куки в инкогнито передаются. иначе сайты бы подали все нафиг в инкогнито

речь про xdomain

речь про xdomain

я конечно не знаю, зачем тебе передавать айди сессии на другой домен, но ты его можешь прицепить как гет-параметр в урл

решил пробросом в заголовке

но всё же некрасиво: if (isset($_SERVER['HTTP_X_XSRF_TOKEN'])) { session_write_close(); session_id($_SERVER['HTTP_X_XSRF_TOKEN']); session_start(); }

и небезопасно, возможно

Приветствую, чёт докатились до стандартизации процесса производства, которое должно вылиться во внутренний и внешний документ для клиентов, проекты становятся сложнее и буксуем в коммуникации и тп, если у кого-то есть внутренние регламенты и всякие документы для клиентов, и не жалко поделиться тезисно - будет интересно почитать, в личку. Agile не предлагать, 99% не поймут 😆

Приветствую, чёт докатились до стандартизации процесса производства, которое должно вылиться во внутренний и внешний документ для клиентов, проекты становятся сложнее и буксуем в коммуникации и тп, если у кого-то есть внутренние регламенты и всякие документы для клиентов, и не жалко поделиться тезисно - будет интересно почитать, в личку. Agile не предлагать, 99% не поймут 😆

1 это не юзать Evo :))))

1 это не юзать Evo :))))

от типа мотыги земля не зависит

от типа мотыги земля не зависит

Это был сарказм :)

Ево это ж инструмент если он под задачи подходит то нет проблем с ним

Ну да, эво говно, php тоже, mysql, jquery 😂

Ну да, эво говно, php тоже, mysql, jquery 😂

Мотыга топ, как раз удобно ей говно разгребать :))

MultiTV > PHP 8.0 issue: Is there a simple solution? « Evolution CMS Parse Error » Error : Undefined array key "templates" https://github.com/extras-evolution/multiTV/blob/master/assets/tvs/multitv/includes/multitv.class.php#L270

MultiTV > PHP 8.0 issue: Is there a simple solution? « Evolution CMS Parse Error » Error : Undefined array key "templates" https://github.com/extras-evolution/multiTV/blob/master/assets/tvs/multitv/includes/multitv.class.php#L270

https://docs.evo.im/04_extras/multitv.html

йоу синьоры, кто-нибудь делал на 1.4 апишечку кроссдоменную? с введением новой политики безопасности хрома пришлось заколхозить startCMSSession() добавил 'samesite' => 'None' Но: 1. сафари похер, куку не ставит 2. в инкогнито не сохраняются куки, соответственно не могу получить сессию

Вообще за такое дело, обычно, отвечает "сервер сессий", который должен быть один для всех доменов. Например, подобным сервером сессий может выступать обычная БД в которую при, допустим авторизации, складывается уникальный id-сессии. Дальше уже логика может быть с перенаправлением и указанием шифрованной id-сессии на нужный домен где уже принимаем из URL данные и смотри существование id-сессии с разными приблудами в общий сервер сессий. Можно расширить безопасность, надеюсь мысль основная ясна. Конечно лучше между API использовать все-таки механизм понятный, типа JWT того же токена и по нему централизовано проверять доступ. Т.е. один домен все равно должен быть "главным". А за "подлоги" данных между серверами браузеры будут и дальше "давать по морде".

jwt использую, но для авторизованных юзеров а сессия нужна всем

да и неважно какой механизм использовать всё-равно session_id не найти получается, если не передавать принудительно

Тогда центральный сервер сессий нужно сделать хотя бы в виде таблицы в БД в которую складывается id-сессии или токен. Чтобы по нему можно было сделать проверку и на новом домене ставить куку и считать что все хорошо.

а если сделать свой обработчик сессий, чтобы они хранились на отдельном сервере в базе?

Про это и речь.

Это и есть сервер сессий.

Просто самый просто вариант это сделать "главный" домен и там проверять.

производительность наверное пострадает

Или добавлять новые, тут как пойдёт

Вот как надо вопрос ставить: задонатите 30$ и я исправлю 30 багов, а если НЕ задонатите, то добавлю ещё 30 новых.

На больших объемах можно RADIUS подключить

Вот как надо вопрос ставить: задонатите 30$ и я исправлю 30 багов, а если НЕ задонатите, то добавлю ещё 30 новых.

Не, я же не плохой человек

Просто самый просто вариант это сделать "главный" домен и там проверять.

это если надо ограничить доступ с доменов. я же просто с фронта на localhost не могу получить сессию какой домен передают мобилки - пока не в курсе Тоже наверное localhost

это если надо ограничить доступ с доменов. я же просто с фронта на localhost не могу получить сессию какой домен передают мобилки - пока не в курсе Тоже наверное localhost

Возможно, потерял нить задачи. В целом раз есть кроссдоменность, то нужна третья сторона не важно что там и как, т.к. домен есть домен.

Не, я же не плохой человек

Ну раз так, то можно добавлять "for glory of Satan 😈"

в связи с введением новых политик безопасности в хроме / сафари кроссдоменные куки не передаются. Evo при создании сессии пишет в куку session_name = session_id И все последующие запросы должны идти с этой кукой. Но если кроссдоменность - то нет куки, соответственно и сессия не поднимается. Вот и вся трабла

Ну раз так, то можно добавлять "for glory of Satan 😈"

https://www.youtube.com/watch?v=_Mbxe33BYW8

в связи с введением новых политик безопасности в хроме / сафари кроссдоменные куки не передаются. Evo при создании сессии пишет в куку session_name = session_id И все последующие запросы должны идти с этой кукой. Но если кроссдоменность - то нет куки, соответственно и сессия не поднимается. Вот и вся трабла

если ты сделаешь хранение сессии на отдельном сервере, то домен вообще не будет иметь значения

ну я полностью механизм сессий видимо не осознаю redis не решит?

ты можешь свой обработчик сессий написать и там хранить где угодно

домены будут отдавать корректные куки

без перепиливания evo ?

а сессия будет одна на все домены

без перепиливания evo ?

В 1.4 нет

надо просто посмотреть, есть ли в ево возможность подсунуть обработчик до того как начнется старт сессии

В 3.0 сессии на редис впилены

домены будут отдавать корректные куки

домен и так отдает корректную куку. но браузер её не сохраняет

вообще, я сделал уже хотелось бы понять - насколько это неправильно / небезопасно / чем грозит

надо просто посмотреть, есть ли в ево возможность подсунуть обработчик до того как начнется старт сессии

В 3.0 если я правильно помню, то можно переназначить обработчик старта сессии. Или я за не дорого могу допилить этот функционал, то что можно подменять обработчик старта сессии

подмешиваю id сессии в заголовки ответа затем проставляю его при последующх запросах в плагине делаю session_start с нужным id из заголовка