@ivanovDA, в качестве альтернативы не пробовали указать эти параметры в Java Options окна свойств Томката?
Прошу прощения, что не указал это ранее, однако до развертывания каких-либо разработанных приложений на Apache дело еще не дошло. Мы делаем просто установку Студию и её запуск по адресу http://localhost:8111/studio
Запуск “CUBA Studio SE.exe” не работает аналогично.
О каком apache идет речь? Мы пока пытаемся добиться того, чтобы сама среда разработки стала нормально работать.
На локальном компьютере разработчика
Я понял. Тут к сожалению, мне поделиться нечем. У себе данный вопрос решил обходным путем с помощью Proxifier. Хотя не могу рекомендовать такой способ.
Буду наблюдать за вашим топиком…
Здравствуйте.
В мы воспроизвели проблему в тестовом окружении и создали тикет в YouTrack.
У Вас действительно не получается создать новый проект?
На 6.8.3 за прокси нам удается создать новый проект и работать с ним. Недоступен только список сэмплов.
Echo, добавленное в studio.bat показывает следущие переменные среды:
JAVA_OPTS="-Dhttp.proxyHost=192.168.56.1"
"-Dhttp.proxyPort=3128"
"-Dhttps.proxyHost=192.168.56.1"
"-Dhttps.proxyPort=3128"
1 симпатия
Здравствуйте!
Да, результат двухдневных исследований. Буквально только что при помощи KeyStore Explorer сохранили сертификаты для:
- *.cuba-platform.com
-
services.gradle.org
Затем
keytool -importcert -keystore “C:\Program Files\Java\jdk1.8.0_162\jre\lib\security\cacerts” -storepass changeit -file C:\Temp\cuba_.cer
и
keytool -importcert -keystore “C:\Program Files\Java\jdk1.8.0_162\jre\lib\security\cacerts” -storepass changeit -file C:\Temp\grandle.cer -alias grandle
После этого стал доступен список версий платфом и загрузился .gradle
Список сэмплов по-прежнему не доступен.
Выглядит не очень хорошей идея вручную кэшировать сертификаты в keystore.
Кроме того, срок действия загруженных сертификатов для cuba-platform.com заканчивается в мае 2018. Не очень привлекательной выглядит идея каждый месяц обновлять сертификаты.
Важный момент в том, что сисадмины контролировали прохождения трафика на checkpoint и на proxy server.
На proxy мы не видим каких-либо отказов в трафике с компьютера разработчика. Почему java при работе со Студией требует таких ручных манипуляций с сертификатами для установки соединения? Неужели для всех https соединений по всем используемым Студией адресам нужно будет указывать сертификаты?
В организации, где много разработчиков данный процесс, с учетом разного срока действия сертификатов, будет выглядеть некрасиво.
Несмотря на то, что нам удалось создать проект в Студии, до сих пор нет уверенности, что все работает по двум причинам:
- Список примеров не работает
- В обсуждении https://www.cuba-platform.com/discuss/t/proxy-server-problems/3077
было рекомендовано скачать и выполнить repo-access-test.zip для проверки соединения.
Скрипт запускается, однако выдает time-out. Если мы в браузере пытаемся открыть ссылки на cuba-platform.com, то на запрос логин-пароль указанные в срипте пара cuba/cuba123 не подходят. Равно как и не подходят admin/admin123.
Честно говоря, впечатление такое, что куда бы ни ткнулись- нигде не работает и мы не можем определить, является ли причиной проблем наши политики на proxy или это баги Студии?
Что можно сделать и что можно проверить еще с нашей стороны, чтобы как это и написано в документации Студия взлетала сразу после установки и настройки всех компонентов в соответствии с документацией и не требовала бы подобных многодневных испытаний для ИТ инфраструктуры и подборов варианта работы, при котором интерфейс начнет работать?
Прошу меня простить, если я погорячился 
. Эмоции после двух изучения форумов и подбора решения методом проб и ошибок …
Добрый день.
В последней версии Студии зарегистрирована единственная проблема касаемая работы через прокси - это недоступность списка примеров. Данная проблема никак не влияет на работоспособность остальной функциональности Студии. Исправлено будет на днях в следующем апдейте 6.8.
Если в вашей сети не работает приложение repo-access-test, это сигнал того что никакое Java приложение стандартным образом с HTTPS серверами работать не будет, в том числе Studio и Gradle.
Вместо репозитория на cuba-platform.com вы можете попробовать использовать Bintray - он содержит все те же артефакты. См. https://doc.cuba-platform.com/manual-6.8-ru/access_to_repo.html
В браузере открыть https://repo.cuba-platform.com/content/groups/work с логином cuba/cuba123 действительно нельзя, это нормально, так как данный пользователь не имеет прав на UI.
1 симпатия
Добрый день!
Спасибо за ответ.
Например, после настройки proxy IntelliJ IDEA работает со своими репозиториями. При первом соединении предложила Accept and Save сертификат в Java keystore с умолчательным паролем changeit и работает, хлеба не просит на той же машине разработчика, что и Студия.
Может, конечно, это не Java приложение? Или оно не с HTTPS серверами работает?
Факт, IntelliJ IDEA репозитории видит и плагины устанавливает с сети без необходимости регистрировать сертификаты вручную в keystore.
Что посоветуете для диагностики причин того, что repo-access-test не работает?
proxifier прошу не рассматривать
Еще момент. Прошу обратить на него внимание.
repo-access-test ломится напрямую минуя proxy несмотря на то, что JAVA_OPTS в переменных среды присутствует.
Чтобы он начал работать через proxy пришлось модифицировать этот тест. Написать:
System.setProperty(“https.proxyHost”, <наш прокси>);
System.setProperty(“https.proxyPort”, <наш порт>);
Таким образом, этот тест не работает через proxy. После того, как мы его доработали, стал выдавать ошибку следующего плана:
Exception in thread “main” javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathB
uilderException: unable to find valid certification path to requested target
Так и должно быть? Это считается, что скрипт отработал корректно?
мы видим, что ошибки одного плана и связаны с сертификатами. Соответственно, не хотелось бы добавлять сертификаты в keystore вручную.
Есть какое-то решение этой проблемы?
Добрый день.
Что касается repo-access-test, вы правы, это мое упущение - он не принимает во внимание параметров окружения. Нужно либо указывать их в коде, как вы и сделали, либо добавить $JAVA_OPTS в командную строку.
По поводу сертификатов. То, что они невалидны в вашей сети, я могу объяснить только одной причиной - они подменяются вашим прокси для перехвата SSL трафика. Так что подмененные сертификаты придется так или иначе импортировать, чтобы Java стала им доверять. IntellIJ делает это замечательно удобно, но я не вижу большой разницы с вариантом командной строки, тем более что вы уже экспортировали эти сертификаты в файлы.
Мы загрузили из файла сертификат сайта со сроком действия. А нужен сертификат удостоверяющего центра.
Мы можем на proxy отключать подмену сертификата для перехвата SSL, но это можно сделать в корпоративной сети для конкретных сайтов. А если со временем список изменится?
Это не надежное решение. Понимаете, это уже лирика и религия. Разница есть и она огромная.
Разница в том, что есть системный подход к созданию продукта, рассчитанный на нормальное коробочное решение и создание продукта конкурентного.
А можно сделать иначе. Все для людей?
IntellIJ делает это замечательно удобно, а Студия это не делает и это не только не удобно. Со стороны Студии практически полностью отсутствует диагностика причин проблем.
Тупо, молча Студия не работает, не показывая никаких сообщений об ошибок работы java.
Танцы с бубном, как это правильно написали в форуме, продолжаются днями, чтобы понять, что не так.
Можно, конечно, посмотреть в логах, если знать где. Реакция в форуме несвоевременная. Я видел, более чем 14 дней человек ждал решения проблем.
В документации на установку Студии этот момент также упущен.
Это проблема, которую приходится решать при помощи третьих средств, таких как keystore explorer и которые, в перспективе, не гарантируют исправление проблем,
поскольку не поддерживаются вашим разработчиком и не описаны в документации. Работаем по принципу: попробуйте, может получится.
Я писал уже раньше, что срок загруженного сертификата- один месяц. На каждой машине разработчика предлагается вручную обновлять сертификаты по окончании срока действия?
Это тупо не правильно и не удобно.
Понимаете, или Студия должна быть доработана для, во-первых, диагностики проблем соединения, затем для работы по принципу IntellIJ.
Есть же перед глазами пример успешной реализации этой задачи. Студия должна формировать сообщения конечному пользователю о проблемах подключения и вариантах исправления.
И документация на установку Студии должна быть дописана для включения в неё описания подобных случаев.
А иначе, вы заставляете разработчиков гуглить и перелопачивать тонны форумов на обеих языках в поисках причин проблем.
Кроме этого, в составе дистрибутива Студии должны быть включены средства диагностики подключения на подобии repo-access-test, но которые работали бы со всеми вариантами
подключения с использованием proxy или без. И этот скрипт также должен выдавать диагностику в виде рекомендаций по настройке Java на компьютере разработчика.
Процесс должен быть простым, прозрачным и полностью контролируемым.
Результатом данного форума мы хотели бы, чтобы или были выполнены доработки Студии, чтобы она работала замечательно удобно как IntellIJ или итоговый комплект,
включенный в документацию, рекомендаций по диагностике и решению проблем подключения, которым мог-бы воспользоваться каждый и гарантированно решить все проблемы с
подключением к репозиториям из Java. На этот момент нужно обратить пристальное внимание, поскольку без подключения к интернет это средство разработки практически бесполезно. И особенно для корпоративных заказчиков со сложной топологией сети.
Гарантированно решить проблемы самостоятельно и в разумные сроки.
Я прошу понять меня правильно. Я написал вам взгляд со стороны конечного пользователя продукта. Конечно, можно проигнорировать его. Настаивать мы, конечно, не можем, однако, надеюсь, что общение могло бы быть конструктивным для обеих сторон. Сейчас я просто не знаю, что делать.
С одной стороны Студия заработала. С другой стороны не нравится, что для её работы нужно вручную скачивать сертификаты и регистрировать их.
Поскольку в корпоративной сети я не контролирую работу prox, а решать вопросы с безопасностью- дело не простое. Усугубляется это тем, что у нас нет полного перечня сайтов для добавления в исключения для настройки proxy. И этого перечня нет в документации на установку Студии или мы пропустили его?
Где можно посмотреть полный перечень URL для настройки исключений?
Студия обращается по следующим адресам:
- к поддоменам *.cuba-platform.com для получения списка примеров, автоапдейта и регистрации подписки
- к репозиторию артефактов, указанному у вас в проекте
Gradle обращается:
- к services.gradle.org для скачивания самого себя
- к репозиторию артефактов, указанному у вас в проекте
По поводу ваших рекомендаций по созданию продукта - спасибо, мы их обязательно учтем.
Спасибо, попробуем сфоримровать список исключений на proxy.
@ivanovDA, Добрый день!
мы выпустили Studio версии 6.8.4, в которой исправлена проблема с прокси. Скачать и ознакомиться со списком всех изменений можно на странице https://www.cuba-platform.ru/download