Судя по этой статье https://jwt.io/introduction/ не получится сделать так, как я хотел: т.е. есть клиентная часть сервиса и есть у него API. При авторизации на клиенте, я не могу использовать токен этой авторизации при кроссдоменных запросов? В случае использования API нужно каждый раз проходит аутентификацию? Либо можно сгенерировать долговременный (постоянный) токен для пользователя (многопользовательский сервис, где у каждого пользователя есть токен для API, так ведь делается, обычно? Но не ясно как такой токен генерировать и закреплять за пользователем или нечто подобное уже реализовано в Laravel?
> Перед каждым запросом ваш браузер спрашивает сервак "а что я могу по этому урлу делать?". Ну и
> сервер возвращает на основе вашего хоста и т.д.
Сервер возвращает после OPTIONS "OK" в моем случае. Потом идёт обычный запрос на получение чего-нибудь и уже в этом запросе есть заголовок Authorization с токеном.
Мне в итоге так и остаётся неясным, как решить мою проблему: предоставить доступ к моему API внешнему миру? Это мне нужен запрос в API сделать, типа getMyToken, чтобы клиент мог получить токен и его передать при кроссдоменном запросе?
Хотел спросить, а на производительность это как влияет? Ведь правильно я понимаю, что в таком случае один проект = одна виртуалка? Нужно для этого как минимум SSD, чтобы например комфортно работать с вагрантом?
А может вы знаете, какие-нибудь обучающие материалы, кроме документации? Спрашиваю на всякий случай, может вы знаете.
Спасибо, интересный вариант, хотя не совсем наверное понимаю в чем существенное различие между первоначальным вариантом с in_array + дополнительно две переменные?
Илья, спасибо, код необязательно было писать, мне непонятно было как лучше было реализовать. К примеру, зачем определять свойство allowIps внутри конструктора, ведь также можно это сделать непосредственно в классе, точнее можно было объявить сразу здесь:
private $allowIps = [
'127.0.0.0',
'0.0.0.0'
];
Также неясно зачем нужен синглтон, как альтернатива - сделать статическим метод isExcluded, и непосредственно к нему обращаться. Вот эти вопросы волнуют меня, но это уже от недостатка знаний/скллов/интеллекта и т.д.
Что-то у меня действительно всё плохо с ООП. В таком случае проверку на IP и вовсе можно вынести в конструктор, а далее просто обращаться к свойству состояния, да?
Под сохранением свойства я имел в виду что-то типа кеширование, нежели оптимизацию. Хотя да, ваше замечание верно, не знаю, мне подумалось, что было бы хорошо, если только один раз делалась проверка.
Получается, мне тогда вообще не нужен синглтон, а просто нужен класс и статический метод проверки.