Иван Шумов, мне не плевать на безопасность, поэтому как только я понял, что токен будет висеть в открытом доступе у всех на виду, сразу начал копать, как его защитить)
Т.е. по глобальной логике, каждый заходящий на страницу пользователь или гость будет получать свой уникальный токен для дальнейшей работы с одним глобальным токеном, который даёт доступ к сервисному АПИ, верно?
Т.е. я правильно понимаю, что нужно логику изменений на странице перенести в php-скрипт и после проверки условий на странице (с помощью JS) отправлять запрос на php-скрипт, чтобы он, в свою очередь, отправил запрос на АПИ с нужной командой и вернул ответ JS'у?
Иван Шумов, я не до конца понимаю весь алгоритм действий...
Регистрировать пользователей - имеется в виду регать их через Auth0 (допустим) и хранить где-то инфу о пользователях?
Просто либо я неправильно сформулировал вопрос, либо не до конца понимаю масштаб проблемы.
Мне ведь просто надо реализовать сценарий, когда "если при загрузке страницы в поле email есть value (там где лежит форма оформления заказа, работает автологин - это конструктор и СРМ в 1 лице), то взять value, отправить запрос в базу по АПИ, и если есть совпадение, то скрыть поле с выбором типа услуги".
Для реализации этого нужно делать обёртку в виде своего кастомного АПИ или юзать Auth0?..
Иван Шумов, ну а если без отдельного своего АПИ вариант с php-прослойкой, которая будет проверять источник запроса (адрес формы заказа) + какие-то скрытые данные и после отправлять запрос к АПИ стороннего сервиса - это нормально?
Иван Шумов, блин, это получается сильно больше работы, чем я предполагал + у меня нет навыков в написании своего АПИ... Плюс мне не нужно никуда никого пускать, есть форма заказа, есть АПИ стороннего сервиса, а я на своей стороне просто хочу проверять введённую почту и на основании ответа менять элементы на странице)
⚡ Kotobotov ⚡, мне не надо каждому пользователю давать токен, я на своей стороне просто хочу проверять введённую почту и на основании ответа менять страницу)
Ну просто меня беспокоит то, что это форма заказа, внутри которой будет лежать видный для всех код: const token = 'asdjhgczvbxcvmnbxcvmxcv';
При желании вы сможете посмотреть, какой я делаю запрос к АПИ (не указал сразу, но я делаю запрос к АПИ через js и fetch) и сделать его самостоятельно. Вот это и пугает.
Обновлять токен тоже не вариант, на стороне сервиса его генерируют 1 раз и дают мне :(
Про обёртку и пускать пользователей не совсем понял.
Цель обращения к АПИ при оформлении заказа пользователем — если в поле ввода имейла есть значение, то его надо проверить на сервисе и если такой имейл там есть, сделать какие-то действия в форме (убрать какие-то поля, установить значения по умолчанию и т.д.)
Значит, можно обойтись без прослойки на внешнем хосте? (из ответа понимаю, что я просто не авторизовался в АПИ, ибо не указан идентификатор партнёра - его ещё получить надо будет).
#, да, пытался в виртуалке (выделял ей 6 Гб) запустить десктоп убунты 19.10
выше в комментах подсказали, что для виртуалки лучше юзать серверную убунту - буду пробовать, но как придет время. я ж честно говорю, что я эникейщик, хочу изучать всё и погружаться в фулл-стэк и пытаюсь бежать впереди паровоза, даже не зная, что из окружения мне нужно собирать.
останусь на винде + буду учиться работать с WSL. а там будет видно. спасибо!
zorca, вынесите мою фразу "нет стека, но уже собираю рабочее окружение" и свой ответ - отмечу решением) Имхо, лучший ответ. Сложно помочь человеку, который (ВОЗМОЖНО) даже не столкнётся с теми проблемами, к которым его готовят. Это не отменяет пользу всех ответов, просто только что осознал, насколько пространственный мой вопрос: буду учить всё, пока не учу ничего, как мне сделать так, чтобы всё было хорошо)
Т.е. по глобальной логике, каждый заходящий на страницу пользователь или гость будет получать свой уникальный токен для дальнейшей работы с одним глобальным токеном, который даёт доступ к сервисному АПИ, верно?