красота какая )

но биего вроде реально один из первых появился )

Там в доках с 1.6 версии нужно юзать tplName

Пробовал. Та же проблема

поколение не то )

для меня это слишком тонкая шутка. Можно раскрыть?

для меня это слишком тонкая шутка. Можно раскрыть?

да это всё про то же ) сейчас фреймворков плодят и этим занимаются все, кто начал на го писать года 2, может 3 назад. сам биего появился года 3 назад? этим занимались те, кому сейчас пофиг на фреймворке и они делают вещи )

хороший фреймворк ускоряет разработку

но его надо знать

Пробовал. Та же проблема

А сразу после генерации аппа все работало ?

И как запускаешь

Мб не из рутовой директории

И как запускаешь

После генерации всё работало. Запускаю из папки, где лежит сам проект go run main.go

Осталось выяснить что изменилось относительно оригинальной сборки

Мб конфиги менял

Сгенерируй рядом еще один апп

Для сравнения

Смотрите. Делаю API. Oauth2. Мой сайт - "морда" к этому API. Аутентифицирую пользователя по PASSWORD. Тут всё ясно. Пользователь на сайте ввел логин пароль, сайт штатным образом по oauth2 полез в мой API. Сервер авторизации слаза в базу, выдал токен. Сайт дальше по нему работает. Усложняем. Хочу аутентификацию по социалочкам. И вот тут... аааа... а как? Кроме как сделать полностью свой API, дублирующий стандартную часть auth-сервера, что-то не придумывается.

Смотрите. Делаю API. Oauth2. Мой сайт - "морда" к этому API. Аутентифицирую пользователя по PASSWORD. Тут всё ясно. Пользователь на сайте ввел логин пароль, сайт штатным образом по oauth2 полез в мой API. Сервер авторизации слаза в базу, выдал токен. Сайт дальше по нему работает. Усложняем. Хочу аутентификацию по социалочкам. И вот тут... аааа... а как? Кроме как сделать полностью свой API, дублирующий стандартную часть auth-сервера, что-то не придумывается.

Апи Щорса :)

Апи Щорса :)

не. суть простая. есть апи. сайт только как фронтенд к нему. разве это не тренд последних лет пяти?

Апи Щорса :)

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

Смотрите. Делаю API. Oauth2. Мой сайт - "морда" к этому API. Аутентифицирую пользователя по PASSWORD. Тут всё ясно. Пользователь на сайте ввел логин пароль, сайт штатным образом по oauth2 полез в мой API. Сервер авторизации слаза в базу, выдал токен. Сайт дальше по нему работает. Усложняем. Хочу аутентификацию по социалочкам. И вот тут... аааа... а как? Кроме как сделать полностью свой API, дублирующий стандартную часть auth-сервера, что-то не придумывается.

Сделать адаптер для каждого типа аутентификации

Сделать адаптер для каждого типа аутентификации

Это понятно. Ещё раз схема. [Сайт] <-Oauth2 API-> [Мой Oauth2 API сервер] <-> [Моя база Users и соответствий Social->User] Я хочу юзера аторизовать через... ну пусть VK.

Ладно, я сегодня сдался и начал водружать osin, двже смирившись с varchar(255) на все поля, и тут мой взгляд упал на UserData interface{}

Ну а как еще юзер дата должна быть представлена ?

Смотрите. Делаю API. Oauth2. Мой сайт - "морда" к этому API. Аутентифицирую пользователя по PASSWORD. Тут всё ясно. Пользователь на сайте ввел логин пароль, сайт штатным образом по oauth2 полез в мой API. Сервер авторизации слаза в базу, выдал токен. Сайт дальше по нему работает. Усложняем. Хочу аутентификацию по социалочкам. И вот тут... аааа... а как? Кроме как сделать полностью свой API, дублирующий стандартную часть auth-сервера, что-то не придумывается.

Это на коленке пишется :) конкретные вопросы ?

Это на коленке пишется :) конкретные вопросы ?

На коленке конечно это не пишется, потому что это как минимум изобретение протокола. Вопрос - есть стандартный протокол? Или может я что-то не заметил и есть устоявшаяся традиция?

Как не пишется, я для ВК как раз таки и на коленке писал:) oauth2 implicit grant flow

в чем протокол?

Как не пишется, я для ВК как раз таки и на коленке писал:) oauth2 implicit grant flow

А зачем мне implicit?

чем отличается аутентификация по логину и паролю от аутентификации через соц сеть?

короткий ответ - ничем

именно

чем отличается аутентификация по логину и паролю от аутентификации через соц сеть?

Тем, что мой REST Server должен выдать access_token првоерив, что я имею доступ к социалочке. Т.е. я должен передать ему его

короткий ответ - ничем

технически всем

Даже так. Под капотом - всем

Ну в спеках же есть точных воркфлоу на каждый случай

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

И oauth2 это о авторизации

А не о аутентификации

Отставить философию. Переформулирую вопрос - есть ли соглашения, спека, устоявшаяся практика, какой я грант тайп должен влепить своему Oauth2 серверу, чтобы он там уже своей магией выдал мне access_token?

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

Да. Это совсем стандартная штука

а зачем грант тайп другой выдавать?

а зачем грант тайп другой выдавать?

Мммм... прости. Но я же не по логину паролю буду аутентифицироваться?

И oauth2 это о авторизации

oauth2 обо всём. в данном случае мы рассматриваем вопрос только аутентификации

ладно, отвечу немного иначе. твой кейс в rfc еще никто не описал )

я бы выдавал грант password

как и для логина / пароля

ладно, отвечу немного иначе. твой кейс в rfc еще никто не описал )

Это ответ. Т.е. какой-то хуеты с JWT/JWE/JWS никому не нужной туда напихали, а тренда лет 5 нет. Но это ответ да

потому что единицы делают oauth2 вокруг oauth2

я бы выдавал грант password

Ну если совсем ничего нет, то я бы сделал грант тип foreign_oauth2 с тупо authorization code

Ну если совсем ничего нет, то я бы сделал грант тип foreign_oauth2 с тупо authorization code

Опс. И с backend

как вариант

если ты будешь это использовать

и в своей доке опишешь эти кейсы

потому что единицы делают oauth2 вокруг oauth2

Топ. Аутентификация по социалкам - на каждом углу вижу. Писать REST API и только поверх него сайт/портал - это не новая тема и вроде как вообще тренд. Или подождите...

я именно про рест апи )

Бля, я ретируюсь, не понимаю что у вас за кейс этакий, я спокойно получаю токен на свой сервер от сервера ВК и делаю с ним запросы, что еще нужно ?

Бля, я ретируюсь, не понимаю что у вас за кейс этакий, я спокойно получаю токен на свой сервер от сервера ВК и делаю с ним запросы, что еще нужно ?

Как? Твоё приложение, которое твой сайт, что запрашивает у твоего Oauth2 API? Какой message flow?

я именно про рест апи )

Ну да, а не Oauth2 мало кто уже RESt делает (хотя делают да)

Зачем тебе еще один аутх сервер, который и так предоставляет ВК?

Бля, я ретируюсь, не понимаю что у вас за кейс этакий, я спокойно получаю токен на свой сервер от сервера ВК и делаю с ним запросы, что еще нужно ?

Ещё раз переформулирую. Твой сайт работает с твоим API по Oauth2. Т.е. он должен получить access_token, подходящий к твоему API. Полученный access_token позволяет работать с ресурсами твоего API от имени пользователя. Вопрос - как наиболее стандартно выглядит message flow для получения от твоего API acess_token, если ты хочешь аутентифицировать пользователя через социалочку?

Зачем тебе еще один аутх сервер, который и так предоставляет ВК?

А разве VK сможет выдать access_token к моему API? Как так?

Уф

Ещё проще - не сайт. Мобильное приложение хочет аутентифицироваться в твоем APi через социалочку

Эти понятия никак не связаны

В одном случае твой сайт клиент

ERROR: S client not available

Твой сервер отвечает

В другом случае клиент твой сервер

И отвечает вк

Точно. Теперь как бы вот у моего сервера спросить соответсвия и получить токен?

Тут интеграция как сделаешь так и будет

То есть не нужно об объединять все под один зонт

Между твоим сервером и твоим сайтом один юзер

Между твоим сервером и вк

Другой

Хоть если они и равны по значению

Но не по ссылке

Если понимаешь о чем я

Хорошо. Я на сайте аутентифицировался в ВК. Сайт хочет получить access_token у моего API используя... опс

А мобильное приложение?

Сервер получает аксес у ВК

А не сайт

После сохраняешь данные у себя в юзере

После сайт просит аксес у сервера

С привязанным ВК аккаунтом к твоему юзеру

После сайт просит аксес у сервера

Вот это самое интересное место. Как он просит? Что он предъявлят моему серверу?

Я сейчас буду пересказывать спеку:)

Я сейчас буду пересказывать спеку:)

Нет. грант какой просить?

http://stackoverflow.com/questions/11327293/oauth2-social-login-flow-allow-oauth2-authentication-via-facebook-twitter-a картинка хорошая

@schors а это точно не задача для JWT?

нужно единожды авторизовать юзера, выдать ему токен и после этого – проверять только токен

или я неправильно понимаю вопрос?

да все верно. авторизовать-то как?

Так. Понятно. Судя по гуглю есть две стратегии - или делается анонимный токен и потом его отдельным нестандартным грантом апдейтят, или есть тупо отдельный грант, куда пихается authorization code и бэкенд.

@schors а это точно не задача для JWT?

ну собственно можно и jwt. но мнится мне, что перспективнее грант тайп новый

И следующий вопрос - двухфакторная авторизация )))) хехе

ну собственно можно и jwt. но мнится мне, что перспективнее грант тайп новый

у JWT главный прикол, как я понимаю, в том, что он сравнительно легко шарится между любым количеством приложений. И не так напоминает туннель во Флориду, как SESS_ID

у JWT главный прикол, как я понимаю, в том, что он сравнительно легко шарится между любым количеством приложений. И не так напоминает туннель во Флориду, как SESS_ID

пока не встает вопрос инвалидации определенного токена)) потом начинаются костыли :D