Anonymous
повторяю еще раз - тест подготавливает окружение для определенного срабатывания определенного кода. а также инструментарий.
определенные ветки кода запустить не так просто. дальше этот тест запускается с отладчиком если нужен его функционал
Sergey
ну и для того чтобы прояснить тебе
tdd - подразумевает написание теста который тебе скажет работает код или нет, он не должен и не будет искать баг, он просто скажет работает или нет
за счет того что это юнит тесты мы точно знаем где не работает
Sergey
процесс отладки это другое - это поиск бага, невсегда явного, но это не тестирование, мы знаем что не работает мы ищем что, как и почему именно не работает и где ошибка
Sergey
повторяю еще раз - тест подготавливает окружение для определенного срабатывания определенного кода. а также инструментарий.
определенные ветки кода запустить не так просто. дальше этот тест запускается с отладчиком если нужен его функционал
можешь повторить еще раз, а можешь просто подтянуть матчасть и не спорить
Anonymous
ты вот не знаешь меня а утверждаешь ))
по тестированию и отладке у тебя явно путаница в голове
по-моему конкруктивная беседа все показывает.
начиная писать всякую хрень вроде того “ты все путаешь ахахаха”
вместо конкретных ответов на конкретные вопросы - уже вполне характеризует человека.
Я конечно тоже скатился в эту плоскоть, но все-таки обосновал все сначала.
Подтягивать матчасть конечно никогда не лишнее. Только я не теоретик, у меня есть поставленный флоу работы, проекты покрытые тестами, методики поиска багов, которые я использую и они работают.
Поиск бага сводится к выяснению входных данных, далее проблемные данные пополняют список входных данных того или иного теста и запуск этого теста позволяет найти ошибку.
По такой схеме я успешно поддерживаю довольно много проектов, это мне дает довольно дофига уверенности перед теоретическими троллями 😉
Alexander
Добрее надо быть друг к другу. И понимать что если у кого-то сделано так, не обязательно что у всех должно быть так и это правильно. Мы тут не Мартины Фауэлеры, писать бест-практисы для остальных.
Alexander
Это к обоим ремарка
Sergey
по-моему конкруктивная беседа все показывает.
начиная писать всякую хрень вроде того “ты все путаешь ахахаха”
вместо конкретных ответов на конкретные вопросы - уже вполне характеризует человека.
Я конечно тоже скатился в эту плоскоть, но все-таки обосновал все сначала.
Подтягивать матчасть конечно никогда не лишнее. Только я не теоретик, у меня есть поставленный флоу работы, проекты покрытые тестами, методики поиска багов, которые я использую и они работают.
Поиск бага сводится к выяснению входных данных, далее проблемные данные пополняют список входных данных того или иного теста и запуск этого теста позволяет найти ошибку.
По такой схеме я успешно поддерживаю довольно много проектов, это мне дает довольно дофига уверенности перед теоретическими троллями 😉
Это ты типа сейчас пытаешься понтануться что крутой разработчик? Смешно. Не стоит пытаться со мной меряться у меня все равно длиннее
Напомню суть твоих утверждений - человеку прочитать джейсон и протобаф одинаково легко, тестирование и отладка это одно и тоже
Все обоснования есть в моих сообщениях, для больших разъяснений Википедия
Alexander
Кто-то вообще тесты не пишет. Потому что код сразу пишет правильный.
Anonymous
Это ты типа сейчас пытаешься понтануться что крутой разработчик? Смешно. Не стоит пытаться со мной меряться у меня все равно длиннее
Напомню суть твоих утверждений - человеку прочитать джейсон и протобаф одинаково легко, тестирование и отладка это одно и тоже
Все обоснования есть в моих сообщениях, для больших разъяснений Википедия
в моем воркфлоу тестирование и отладка одно и то же, да.
Anonymous
Это ты типа сейчас пытаешься понтануться что крутой разработчик? Смешно. Не стоит пытаться со мной меряться у меня все равно длиннее
Напомню суть твоих утверждений - человеку прочитать джейсон и протобаф одинаково легко, тестирование и отладка это одно и тоже
Все обоснования есть в моих сообщениях, для больших разъяснений Википедия
я не понтуюсь, а обосновываю почему я имею свое мнение.
в чьих-то словах всегда есть источник.
ответы без пояснений, вместо этого понты и ссылки на гугол и википедию - показатель уровня общения разработчика, я бы таких коллег гнал ссаной метлой
Sergey
я не понтуюсь, а обосновываю почему я имею свое мнение.
в чьих-то словах всегда есть источник.
ответы без пояснений, вместо этого понты и ссылки на гугол и википедию - показатель уровня общения разработчика, я бы таких коллег гнал ссаной метлой
Ты мал ещё кого то гнать))
Твоя аргументация - я крут, у меня много проектов и это мой воркфлоу
Моя аргументация несколько проще - читать джейсон удобнее потому что он не бинарный
Тестирование и отладка это разные процессы, даже если в твоём воркфлоу это одно и тоже, для подробностей в чем разница в Википедия ибо нет смысла сюда её копировать
Sergey
А основную суть различия этих процессов я пояснил в сообщениях выше
Sergey
На этом все, диалог с тобой не интересен
Anonymous
все что я пишу просто подтверждается в каждом ответном сообщении
Anonymous
если надо что-то выводить жсон не жсон для этого пишется тестовая среда и там это выводится в удобном виде
да можно продолжать плакать что ведь когда я ищу ошибку я запускаю дебаггер и он просто выводит содержимое переменной а там байты, чем сделать удобный для разработки флоу.
зато по википедии - неудобно отлаживаем отдельно, тестируем отдельно.
Lee
Valentin
@twentydraft тут срутся
Anonymous
https://golang.org/conduct#unwelcome_behavior
Anatoliy
Ребят, поясните пожалуйста. Вот я использую JWT для аутентификации пользователя. Вот отправил ему этот токен, он действует 5 минут. Что происходит через 5 минут? По идее он истекает и я теперь не даю пользователю делать что он делать должен, я его воспринимаю как гостя. Но! Не буду же я кажыде 5 минут спрашивать пароль, верно? Как этот момент вообще решается при работе с токенами?
Slava
ну если токен на пять минут, значит пользователь должен опять аутентификацию пройти
Alexander
вообще конечно статью бы почитать какую. jwt же разжеван, донельзя. считается хорошей практикой - давать два токена. один для аутентификации, второй - рефреш-токен.
Anatoliy
Это понятно, но я ведь не буду каждые 5 минут пароль спрашивать, верно? А токены как я понимаю используются именно по той причине что они быстро истекают, и при получении их злоумышленник не сможет надолго получить доступ к системе
Anatoliy
вообще конечно статью бы почитать какую. jwt же разжеван, донельзя. считается хорошей практикой - давать два токена. один для аутентификации, второй - рефреш-токен.
вот, если скажете теги по которым можно искать - буду вообще благодарен, про второй токен знаю, но как их "отделить" - пока не понятно
Anatoliy
Впрочем спасибо, про второй токен сам не подумал, хоть и слышал, все что нужно нашел) Благодарю)
Alexander
да не за что. плюс надо учитывать что jwt в целом не особо подходит для "стандартных" веб-приложений, имхо. там лучше старые добрые сесии и кукисы. а жвт для мобильного бекенда. или если какие-то микросервисы должны друг с другом "защищенно" общаться
Vsevolod
Anatoliy
Alexander
какие эти самые? на стороне сервера не надо токены хранить
Anatoliy
у нас есть в итоге access token & refresh token, так? и как я понял jwt является access токеном, и мы ему верим, но есть же еще refresh token?
Alexander
угу, с refresh токеном мы идем, если access-токен заэкспарился.
Alexander
и получаем новый access.
Alexander
ну и политику обновления и отзыва refresh-токена надо продумывать отдельно.
Anatoliy
но хорошо, допустим я храню Access token в куках, и при каждом вызове страницы он отправляется, а где я храню тогда рефреш токен?
Anatoliy
вот тут уже кто как для себя решает
вот если мы получаем его вместе каждый раз - то придумывать не надо, старый просто перестает действовать
Alexander
вот если мы получаем его вместе каждый раз - то придумывать не надо, старый просто перестает действовать
рефреш-токен действует длительное время, поэтому если его угонят, то потенциального вреда от этого будет больше. а если мы каждый раз будет рефреш-токен обновлять, то потенциально мы злоумышленника не знающего пароль никогда не выкинем
Alexander
поэтому я бы просто так рефреш-токены не обновлял.
Anatoliy
рефреш-токен действует длительное время, поэтому если его угонят, то потенциального вреда от этого будет больше. а если мы каждый раз будет рефреш-токен обновлять, то потенциально мы злоумышленника не знающего пароль никогда не выкинем
вот как раз когда настоящий пользователь войдет в систему - злоумышленника сразу выкинет
Anatoliy
именно потому что рефреш токен как я понял может быть только один на пользователя
Alexander
а так, выкинет сразу как только заэкспарится экссесс-токен, если злоумышленник не угнал рефреш.
Alexander
а если угнал и его тоже, то выкинет как истечет время жизни рефреш-токена
Anatoliy
если угнал access токен - да, а если угнал рефреш что произойдет? он будет год иметь доступ?
Alexander
ну я говорю, тут каждый для себя решает как правильно
Anatoliy
рефреш - долгоживущий
Alexander
угу, ясен перец. но год ставить - перебор
Anatoliy
5 минут на access и месяц на рефреш
Anatoliy
в итоге раз в 5 минут мы делаем обращение к базу и пересобираем пару токенов, но если запросов тысячи в секунду - то мы уже хорошо так времени экономим
Anatoliy
но все же не понятно где их хранить, я про то что нормально ли оба токена хранить в куках
Alexander
ну зависит от того, что на фронте. я хз, где сейчас новомодные js фреймворки данные хранят ? там же есть теперь "локальный сторедж", такая сущность?
Alexander
я бы слал рефреш-токен не в каждом запросе, а только на обновление экссесс-токена
Alexander
ну и хранить на клиенте так, как умеешь
Sergey
Почитайте про oauth (чтобы понять про refresh и access токены)
Но вам тем не менее скорее всего не это нужно
Anatoliy
я бы слал рефреш-токен не в каждом запросе, а только на обновление экссесс-токена
вот я бы тоже, но тогда на клиенте надо это дело проверять, а я думал просто игнорить на сервере до поры до времени приходящий рефреш и если что его просто использовать для новой генерации Access токена
Anatoliy
Почитайте про oauth (чтобы понять про refresh и access токены)
Но вам тем не менее скорее всего не это нужно
oauth мне не нужен, это да
Anatoliy
мне просто нужна нормально работающая аутентификация на микросервисах
Sergey
Суть в том что рефреш служит только для обновления токена доступа и его обновлять не надо
Anatoliy
То что он служит только для обновления access - я согласен.
Но вот то что его самого не надо обновлять - под вопросом...
https://habrahabr.ru/company/Voximplant/blog/323160/
Sergey
Честно, лень читать
По факту в большинстве систем рефреш не обновляют ибо это излишне
Anatoliy
Просто надо для себя решить может ли пользователь иметь несколько refresh токенов. Если может - тогда возникает веселая штука с логином на нескольких устройствах одновременно и надо придумывать способ как можно определить что пользователь может залогиниться и отрубить другие рефреш токены. Впрочем решается тоже просто - нужная страница доступна только первому access токену который мы получаем вместе с рефреш сразу после ввода логина
Anatoliy
Ладно, в любом случае спасибо за беседу, было интересно)
Sergey
Рефреш нужен один и он не используется для доступа совсем
Sergey
Для доступа используется access token, вы не сможете его получить без рефреш токена но именно он используется для доступа к ресурсам
Sergey
Access токенов может быть более одного
Anatoliy
Так я и не спорю что для доступа только access используется.
Anatoliy
А из тех кто macaron пользует может кто пояснить одну вещь?)
Есть вот такое:
type TokenHandler struct {
SecretKey []byte
DBConn *sql.DB
}
...
handlerStruct := &controller.TokenHandler{
SecretKey: []byte(KEY_SECRET),
DBConn: db,
}
...
m.Post("/", binding.Json(controller.User{}), handlerStruct.CreateUser)
...
func (h *TokenHandler) CreateUser(c *macaron.Context) {
...
Как мне в сам CreateUser передать полученного пользователя?
Anatoliy
По примерам посмотрел - но там именно обработка, а мне то дальше надо передать...
Anonymous
Есть кто с новосибирска? С утра в запой на 1-2 дня.
Anonymous
кто шарит в nginx?
Anonymous
а где он?
Egor
Последний раз слышал на high load конфе в этом году
Egor
🍗
Можно в консоли после того как вывели в консоль текст fmt.Println('text'); изменить/заменить выведенное слово ?
Anonymous
Можно в консоли после того как вывели в консоль текст fmt.Println('text'); изменить/заменить выведенное слово ?
fmt.Printf("\rновый текст")
Anonymous
Надеюсь с направлением слеша не ошибся