Скорее всего сначала нужно зарегистрироваться вот тут https://www.instagram.com/developer/ и создать там "приложение" для которого получите айди приложения, секретный ключ, возможно еще что-то. В настройках "приложения" вам нужно будет прописать урл редиректа - страницы вашего приложения на которую будет перенаправлен пользователь после успешной или неуспешной авторизации.
В SPA при клике у вас должен происходить редирект на страницу авторизации Instagram (вероятно в урле или где-то еще должен быть айди вашего "приложения"), после авторизации Instagram редиректит на указанный вами урл добавляя в урл авторизационный код, который на бэкэнде должен быть прочитан, записан.
<Пасспорт>
После отправляется с сервера запрос аксес токена к инстаграмму с этим сохраненным кодом. Получив аксесс токен можно отправить запрос для получения имейла и другой информации инстаграм пользователя. Пасспорт>
После чего найти пользователя в базе пользователей по имейлу и если такого нет, то создать его. Выделенную часть берет на себя пасспорт. На оф. сайте должны быть уже готовые стратегии и для фб и для инстаграмма и для контакта.
В статье по протоколу это называется самой сложной, но и самой надежной схемой авторизации. Увы подробнее я вряд ли смогу описать.
Дмитрий Королёв, ну какая разница? Люди все равно будут заходить, читать. А у вас в комментарии неточности и глупости есть. Для сохранения данных в куках не обязателен бекэнд и запросы на сервер. Есть просто джаваскрипт функционал для\ записи куков в браузере. Про отсутствие подводных камней мой пост выше. И это не новая информация.
Есть проблемы с событием “storage” в ИЕ 11 и ИЕ 10
Кроме всего прочего локальное хранилище записывается на диске устройства, хранилище загружается при первом запуске, а учитывая, что чтение хранилища является синхронным, то это блокирует загрузку страницы особенно это может быть ощутимо при запуске браузера с множеством вкладок. Впрочем альтернатив особых нет - куки малы если нужно много данных хранить, а локальные базы данных имеют поддержку значительно хуже среди браузеров.
Бывало так что дизайнер просто нарисовал не зная как это будет реализовано в разметке. Например нарисовал огромные красные цыфры обратного отсчета перекрывающие фото кроссовка так словно цыфры материальны, наложил на кросовки рефлексы красного. Выглядит красиво. Но для реального примера этой картинки недостаточно. Нужна полная картинка кросовок и рефлексы пришлось убрать поскольку цыфры то меняются. Можно отправить запрос клиенту на изменение дизайна и ждать долго ответа. А дизайнер еще не сразу поймет что от него хотят и тут еще дополнительная имейл переписка. Или можно самому все в фотошопе сделать. Так что как посмотреть.
iwtbf: на экранах c пропорциями ближе к квадрату разместить текст и картинку на одном уровне и чтоб они не вылазили за скос и не обрезались становиться почти невозможно при скосе в 45 градусов. На мобилке даже говорить нечего. Возможно значительно уменьшить угол. Ну так для справки
cattrue же один. к нему бесмысленно применять nth-child. Его применяют к элементам которые на одном уровне лежат и имеют одного общего непосредственного родителя.
Снова я. У меня тут немного новой информации появилось. Может в этом ключе пригодится.
Вчера на собеседовании мне задали вопрос как оцентровать в окне скажем картинку (рекламу) размер которой заранее неизвестен только с помощью CSS но без флексбокса, без псевдоселекторов и без вертикального выравнивания и дополнительного оборачивающего растянутого на весь экран блока.
Фишка этого приема еще в том, что если окно меньше картинки, то центр картинки все равно остается в центре видимой области.
Периодически встречается задача оцентровать блок внутри другого блока. Внешний блок может быть как больше внутреннего так и меньше в зависимости от экрана. Тот же подход, но вместо position: fixed - position: absolute или position: relative (в зависимости от задачи), а внешнему блоку соответственно position: relative.
Ingernirated: Не думаю, что отсутствие адреса у ссылки отменяет действие браузера по умолчанию. Просто при отсутствии адреса или якоря обработчик по умолчанию ничего не сделает. Но он будет вызван.
А теперь приблизительная последовательность.
1. Ты кликнул.
2. Браузер проверили есть ли пользовательские обработчики события и сформировал очередь обработчиков события клик на этой ссылке. Последний в очереди обработчик события по умолчанию.
3. Первым выполняется твой обработчик который меняет несколько значений объекта элемента ссылки. Скорее всего после этого бразуер установит в конец очереди операцию перерисовки ДОМ-узла
4. Выполняется обработчик по умолчанию. Который проверяет значение href объекта. Оно не пусто - как раз перед этим твой обработчик сделал его равным "www.w3s.com". Следовательно инициируется переход.
5. Ну еще наверное успевает отработать перерисовка ДОМ-узла ссылки.
Скорее всего сначала нужно зарегистрироваться вот тут https://www.instagram.com/developer/ и создать там "приложение" для которого получите айди приложения, секретный ключ, возможно еще что-то. В настройках "приложения" вам нужно будет прописать урл редиректа - страницы вашего приложения на которую будет перенаправлен пользователь после успешной или неуспешной авторизации.
В SPA при клике у вас должен происходить редирект на страницу авторизации Instagram (вероятно в урле или где-то еще должен быть айди вашего "приложения"), после авторизации Instagram редиректит на указанный вами урл добавляя в урл авторизационный код, который на бэкэнде должен быть прочитан, записан.
<Пасспорт>
После отправляется с сервера запрос аксес токена к инстаграмму с этим сохраненным кодом. Получив аксесс токен можно отправить запрос для получения имейла и другой информации инстаграм пользователя.
Пасспорт>
После чего найти пользователя в базе пользователей по имейлу и если такого нет, то создать его. Выделенную часть берет на себя пасспорт. На оф. сайте должны быть уже готовые стратегии и для фб и для инстаграмма и для контакта.
В статье по протоколу это называется самой сложной, но и самой надежной схемой авторизации. Увы подробнее я вряд ли смогу описать.