более того при обмене кода (который получаете при установке) на токен, вы также отправляете и client_id и client_secret, т.е. теоретически если сделать какой-нибудь MitM, то по сути все секретики у тебя будут, чтобы перехватить управление данными от интеграции.
аналогично и при запросе свежего access_token мы передаем client_id, client_secret и refresh_token
логичнее было бы передавать какой-нибудь хеш от refresh_token+cleint_secret, который на своей стороне амо могла также воспроизвести и сравнить воспроизведенный с полученным.
механизм не так плох, единственно, что напрягает, что с машины разработчика пока реализуешь нужную функциональность по десять раз потребуется получать свежий access_token
с одной стороны его таки не сложно получить, но все же нужна какая никакая инфраструктура, т.е. сервер, который примет код, и ты его поменяешь на токен
чтобы меньше заморачиваться на это и каждый раз не объяснять тем, кто у нас недавно начал заниматься виджетами под амо, с коллегой записали видео https://www.youtube.com/watch?v=CxQcB5AsyHI может кому сделает жизнь проще и съэкономит время на разборки с пониманием амо
первая рекомендация: понять на каком этапе ваш проект
если проект на начальной стадии - например, вы работаете один, вы тестируете гипотезы, что-то тестируете, и при этом результаты фиксируете в репозиторий - то никто не будет читать ваши коммиты - забейте и пишите что хотите
если проект растет и вас два-три человека - но вы общаетесь, обсуждаете, все в курсе всего - никто не читает коммиты - забейте и пишите что хотите
если ваш проект подрос, начал использоваться вами в рабочей среде, вы стали реже в него писать - о, да, пора писать суть в коммитах, но если там пару опечаток поправили - забейте и напишите fix
если уже проект подзаматерел, работает, вы начали версионировать, да и команда побольше и проект стал частью чего-то большего - пора применять правила написания коммитов )))
Его нет. Это не пользовательское хранилище файлов, а такое общее служебное для сервисов. Сервисы хранят уникальные ссылки. Примерно как ролики на Ютубе с доступом по ссылке. Есть ссылка? можешь скачать. Нет ссылки? Тогда и не знаешь, что качать. И пользовательские списки файлов и доступ к ним контролируют уже сервисы сами, filebump - это некоторая такая замена файловой системы для сервиса.
что такое S3? AWS? там вроде платить надо? т.е. не был знаком, отсюда надо время разобраться. или свой http по-быстрому запустить? или с minio разбираться? или взять zenko? на начальном этапе было проще свое на коленке сделать, два метода и готово, закрыть потребность, протестировать такой вынос файлообмена. А вот сейчас, когда растет список пожеланий и хотелок, понемногу появляется вопрос - улучшать свое или выбросить и взять что-то уже существующее?
вы используете minio? или подобные fileshare? удобно? а для чего? какие кейсы использования?
а можно ли в этом low-code как-то все-таки разрабатывать как разработчик? то есть есть ли low-git и можно ли как-то организовать low-deploy? ))
т.е. вы разработали таск-трекер. вот он работает, люди пользуются. вы хотите сделать новую фишку, на другом аккаунте собрали таск-трекер с новой фишкой, потестировали, решили сделать на рабочем аккаунте. и как перенести?
для разработки виджета проще использовать что-то типа
https://github.com/jasper7466/Boilerplate-amoCRM-Widget
https://github.com/max-kut/amocrm-widget-starter-kit
для получения oAuth токена
https://youtu.be/CxQcB5AsyHI
из примера в пример эти
curl_setoptкочуют ))для тех кто хочет начать разрабатывать для амо свои интеграции записал видео как запустить интеграцию на своей машине, получать данные с амо
https://youtu.be/CxQcB5AsyHI
https://youtu.be/zRlO7e41bwg
более того при обмене кода (который получаете при установке) на токен, вы также отправляете и client_id и client_secret, т.е. теоретически если сделать какой-нибудь MitM, то по сути все секретики у тебя будут, чтобы перехватить управление данными от интеграции.
аналогично и при запросе свежего access_token мы передаем client_id, client_secret и refresh_token
логичнее было бы передавать какой-нибудь хеш от refresh_token+cleint_secret, который на своей стороне амо могла также воспроизвести и сравнить воспроизведенный с полученным.
механизм не так плох, единственно, что напрягает, что с машины разработчика пока реализуешь нужную функциональность по десять раз потребуется получать свежий access_token
с одной стороны его таки не сложно получить, но все же нужна какая никакая инфраструктура, т.е. сервер, который примет код, и ты его поменяешь на токен
чтобы меньше заморачиваться на это и каждый раз не объяснять тем, кто у нас недавно начал заниматься виджетами под амо, с коллегой записали видео https://www.youtube.com/watch?v=CxQcB5AsyHI может кому сделает жизнь проще и съэкономит время на разборки с пониманием амо
спасибо за статью, помогла
сейчас можно использовать '@webdiscus/pug-loader' на замену оригинальному, поддерживает pug 3
Пользователи linux: ну да, ну да, драйверов на принтеры иногда нет))
>> Open-source невозможно монетизировать
может быть в этом весь кайф? ))
интересная мотивация, конечно: ни конфигурировать нормально, ни внимание встрече уделить )))
хотя аналог ctop'а в тг может быть и нужен
и сильно помогает? со временем логика архитектурных решений меняется, особенно в длительных проектах
первая рекомендация: понять на каком этапе ваш проект
если проект на начальной стадии - например, вы работаете один, вы тестируете гипотезы, что-то тестируете, и при этом результаты фиксируете в репозиторий - то никто не будет читать ваши коммиты - забейте и пишите что хотите
если проект растет и вас два-три человека - но вы общаетесь, обсуждаете, все в курсе всего - никто не читает коммиты - забейте и пишите что хотите
если ваш проект подрос, начал использоваться вами в рабочей среде, вы стали реже в него писать - о, да, пора писать суть в коммитах, но если там пару опечаток поправили - забейте и напишите fix
если уже проект подзаматерел, работает, вы начали версионировать, да и команда побольше и проект стал частью чего-то большего - пора применять правила написания коммитов )))
как автор проекта я бы не рекомендовал ))
я по прежнему использую проект, но как-то не вижу его перспективы в таком виде
Нашел подобный сервис https://upload.io/ , а filebump - это свой локальный вариант.
Его нет. Это не пользовательское хранилище файлов, а такое общее служебное для сервисов. Сервисы хранят уникальные ссылки. Примерно как ролики на Ютубе с доступом по ссылке. Есть ссылка? можешь скачать. Нет ссылки? Тогда и не знаешь, что качать. И пользовательские списки файлов и доступ к ним контролируют уже сервисы сами, filebump - это некоторая такая замена файловой системы для сервиса.
А что вы используете? А какие кейсы? Так-то голосовать можно за что угодно. Были ли примерно схожие задачи?
вообще нет. скорее, ход рассуждения, но да ладно, заминусили знатно ))
что такое S3? AWS? там вроде платить надо? т.е. не был знаком, отсюда надо время разобраться. или свой http по-быстрому запустить? или с minio разбираться? или взять zenko? на начальном этапе было проще свое на коленке сделать, два метода и готово, закрыть потребность, протестировать такой вынос файлообмена. А вот сейчас, когда растет список пожеланий и хотелок, понемногу появляется вопрос - улучшать свое или выбросить и взять что-то уже существующее?
вы используете minio? или подобные fileshare? удобно? а для чего? какие кейсы использования?
На КДПВ - это Сундар Пичаи, Риши Сунак и Кунал Найар?
У статьи не хватает тега Юмор?
так она потому и гибкая и расширяемая, если ты можешь на ней переписать несколько раз ))
а можно ли в этом low-code как-то все-таки разрабатывать как разработчик? то есть есть ли low-git и можно ли как-то организовать low-deploy? ))
т.е. вы разработали таск-трекер. вот он работает, люди пользуются. вы хотите сделать новую фишку, на другом аккаунте собрали таск-трекер с новой фишкой, потестировали, решили сделать на рабочем аккаунте. и как перенести?
"молодцы, хотелось бы добавить юмора..." (с)