Эх... Может sql напрямую передавать :) наверное этим все и кончится :)

нет, нет и ещё раз нет. Только в том случае если совсем поехала кукушка

добрый вечер может кто подсказать библиотеки для того чтоб зашифровать строку на js а расшифровать на go

гугли AES

уже час гуглю не могу дойти до нужных библиотек

уже час гуглю не могу дойти до нужных библиотек

go aes js aes подсказываю запросы в гугл

есть "crypto/aes" но не ясно как проводить шифрование и дешифровку пользовался кто нибудь

go aes js aes подсказываю запросы в гугл

на js библиотек как г,,,на на го не могу понять как делать

есть "crypto/aes" но не ясно как проводить шифрование и дешифровку пользовался кто нибудь

https://golang.org/src/crypto/cipher/example_test.go

нет, нет и ещё раз нет. Только в том случае если совсем поехала кукушка

Если тема пройдет в массы, этим и должно будет все закончится. Как по мне, это самый логичный способ. Ну может не табличку отдавать, а может и табличку, но не одну... Но sql отличный язык для этого.

Зачем какой-то новый язык запрос изобретать.

https://golang.org/src/crypto/cipher/example_test.go

спасибо попробую еще раз разобраться

Зачем какой-то новый язык запрос изобретать.

затем, чтобы абстрагировать хранилище от клиента

гугли AES

а я бы советовал ассиметричное шифрование

SPARQL - вот где следующее будущее, а вы все GRAPHQL... можно немного тут почитать https://habr.com/post/309448/

Если тема пройдет в массы, этим и должно будет все закончится. Как по мне, это самый логичный способ. Ну может не табличку отдавать, а может и табличку, но не одну... Но sql отличный язык для этого.

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

а я бы советовал ассиметричное шифрование

Сильное заявление.

а я бы советовал ассиметричное шифрование

а я бы не советовал. ассиметричное шифрование всегда: 1. медленее (AES-NI ускоритель имеется в практически каждом CPU) 2. более уязвимо к потенциальным угрозам (Shor's alg. на квантовом компе ломает Diffie-Hellman asym. encr. а вот AES256 даже ему не сломать)

как мне это надоело, а?.. про задачу ни одного вопроса не задали, но уже оптимизировали по параметру "производительность".

Асимметричное шифрование чтобы зашифровать ключ, которым дальше будет aes шифровать

а кто-то уже пробовал graphql внедрять?

SPARQL - вот где следующее будущее, а вы все GRAPHQL... можно немного тут почитать https://habr.com/post/309448/

и чем он лучше GrahpQL? они хоть из одной и той-же лиги то?

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

Ты меня не понял, начнем с этого. Мы и так отдаем базу клиенту, только интерфейсом у нас rest или граф. Sql это такой же интерфейс. Никто не говорит что его нужно выполнять напрямую с клиента, но они отлично может подойти для описания запросов.

как мне это надоело, а?.. про задачу ни одного вопроса не задали, но уже оптимизировали по параметру "производительность".

человек сам поймёт когда ему нужно ассиметричное шифрование, в любом другом случае всегда стоит использовать AES

а кто-то уже пробовал graphql внедрять?

ну мы пробовали

как мне это надоело, а?.. про задачу ни одного вопроса не задали, но уже оптимизировали по параметру "производительность".

Чувак ничего не конкретизировал что ему требуется от шифрования, а ему уже предложили более сложное и с кучей мест, где можно потенциально наебаться шифрование.

ну мы пробовали

какой клиент использовали? apollo, relay-classic, relay-modern?

Чувак ничего не конкретизировал что ему требуется от шифрования, а ему уже предложили более сложное и с кучей мест, где можно потенциально наебаться шифрование.

коллега, вы просто безграмотны, похоже. как вы собираетесь ключами обменяться для симметричного шифрования?

и чем он лучше GrahpQL? они хоть из одной и той-же лиги то?

Не совсем из той же, sparql будет более универсальным, но думаю не сразу

какой клиент использовали? apollo, relay-classic, relay-modern?

apollo

Ты меня не понял, начнем с этого. Мы и так отдаем базу клиенту, только интерфейсом у нас rest или граф. Sql это такой же интерфейс. Никто не говорит что его нужно выполнять напрямую с клиента, но они отлично может подойти для описания запросов.

мы отдаём не базу, а данные, не путайте эти слова. нет, SQL это не такой же интерфейс как REST или GQL. Учите мат-часть, коллега

коллега, вы просто безграмотны, похоже. как вы собираетесь ключами обменяться для симметричного шифрования?

Обменивался при личной встрече на флэшке один раз в жизни

человек сам поймёт когда ему нужно ассиметричное шифрование, в любом другом случае всегда стоит использовать AES

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

Обменивался при личной встрече на флэшке один раз в жизни

да, я об этом

apollo

вы вместе с Романом работаете?

вы вместе с Романом работаете?

нет, это ответ от моего опыта внедрения

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

Асиметричное тянет за собой симметричное же. Тот же RSA ограничен по длине шифротекста. Так что им получается зашифровать только ключ симетричного шифрования.

нет, это ответ от моего опыта внедрения

а можете поделиться почему apollo выиграл у relay-modern?

какой клиент использовали? apollo, relay-classic, relay-modern?

честно? никакой. просто plain string query. это у нас ещё нерешённый вопрос с кэшированием (по сути клиент нужен только для этого) выше перечисленные клиенты требуют соответствующие серверные имплементации, которые мы не юзаем

а можете поделиться почему apollo выиграл у relay-modern?

с relay-modern не сравнивал. Выбирал больше года назад - тогда видимо существовал тот relay, который стал classic. По сравнению с ним более гибкий, бесшовно интегрируемый в реакт-проекты, большое кол-во статей

честно? никакой. просто plain string query. это у нас ещё нерешённый вопрос с кэшированием (по сути клиент нужен только для этого) выше перечисленные клиенты требуют соответствующие серверные имплементации, которые мы не юзаем

какое кэширование нужно?

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

ассиметричное? быстрее и проще и надёжнее? т.е. плевать на то что ECDH и RSA ломаются алгоритмом Shor'а на квантовом процессоре? плевать на то что ECDH и RSA не ускоряются на уровне железа? и то что ассиметрия с private public key проще это вообще нонсенс... помню лицо коллеги, когда я в 18 лет отдал ему private key на запрос дать ему мой ключ... я тогда ещё шифрование вообще не понимал в то время как симметричное было вполне для меня интуитивным, мол есть ключ, им открывается и закрывается..

с relay-modern не сравнивал. Выбирал больше года назад - тогда видимо существовал тот relay, который стал classic. По сравнению с ним более гибкий, бесшовно интегрируемый в реакт-проекты, большое кол-во статей

а что на бекенде было у вас?

ассиметричное? быстрее и проще и надёжнее? т.е. плевать на то что ECDH и RSA ломаются алгоритмом Shor'а на квантовом процессоре? плевать на то что ECDH и RSA не ускоряются на уровне железа? и то что ассиметрия с private public key проще это вообще нонсенс... помню лицо коллеги, когда я в 18 лет отдал ему private key на запрос дать ему мой ключ... я тогда ещё шифрование вообще не понимал в то время как симметричное было вполне для меня интуитивным, мол есть ключ, им открывается и закрывается..

Чушь

Чушь

о боже... понятно

какое кэширование нужно?

client-side caching

а что на бекенде было у вас?

го. мы на самом деле с тобой год назад общались на эту же тему, и ответы были те же

client-side caching

ну в аполло есть кэширование

по-моему там вообще с этим все хорошо

го. мы на самом деле с тобой год назад общались на эту же тему, и ответы были те же

хаха, ну видимо я так и не решился на graphql тогда

какое кэширование нужно?

вот на неделе нашёл https://github.com/FlacheQL/FlacheQL

мы отдаём не базу, а данные, не путайте эти слова. нет, SQL это не такой же интерфейс как REST или GQL. Учите мат-часть, коллега

Мелко мыслишь. Матчасть я уже больше забыл, чем ты изучал. Думаю на этом можно закончить обсуждение.

по-моему там вообще с этим все хорошо

цитирую FlacheQL offers partial retrieval of cached data based on search parameters — a feature that no other GraphQL library offers. Larger implementations like Apollo and Relay can only cache data based on GraphQL query fields.

Мелко мыслишь. Матчасть я уже больше забыл, чем ты изучал. Думаю на этом можно закончить обсуждение.

я вижу как вы её изучали, SQL от GQL отличить не можете)) да, завершаем этот бесполезный "спор"

А вообще - у меня есть доклад про разработку шифропротокола на базе AES На английском, правда

А вообще - у меня есть доклад про разработку шифропротокола на базе AES На английском, правда

ну хорошо, и как этот факт делает ассиметричное шифрование быстрее?

если бы оно было быстрее то мы бы не парились с key-exchange в HTTPS, просто бы шифровали всё в RSA/ECDH... но нет... зачем-то понадобился им AES... не потому-ли что он а) быстрее б) имплементировал в железе инструкциями типа AES-NI?

я вижу как вы её изучали, SQL от GQL отличить не можете)) да, завершаем этот бесполезный "спор"

Есть ощущение что вы не знаете что такое sql

цитирую FlacheQL offers partial retrieval of cached data based on search parameters — a feature that no other GraphQL library offers. Larger implementations like Apollo and Relay can only cache data based on GraphQL query fields.

окей. но это не требует серверных решений.

Есть ощущение что вы не знаете что такое sql

у меня скорее ощущение что люди не знают GQL и наивно сравнивают его с SQL, хотя это вещи совершенно разные. нет, SQL не лучше GQL для API, начиная с того что моделирование взаимосвязей в SQL с помощью JOIN'ов и foreign ключей это боль... грубо говоря: SQL vs GQL == tables vs graph // true

окей. но это не требует серверных решений.

помоему нет, но я ещё не успел сию тему изучить, надо будет как нибудь с ней поиграться

помоему нет, но я ещё не успел сию тему изучить, надо будет как нибудь с ней поиграться

да и что-то проект вроде затих - коммитов нет

да и что-то проект вроде затих - коммитов нет

вообще тема кэширования в GQL осносительно сложная, я её ещё не затрагивал

у меня скорее ощущение что люди не знают GQL и наивно сравнивают его с SQL, хотя это вещи совершенно разные. нет, SQL не лучше GQL для API, начиная с того что моделирование взаимосвязей в SQL с помощью JOIN'ов и foreign ключей это боль... грубо говоря: SQL vs GQL == tables vs graph // true

Причём тут сравнение gql vs sql?

если бы оно было быстрее то мы бы не парились с key-exchange в HTTPS, просто бы шифровали всё в RSA/ECDH... но нет... зачем-то понадобился им AES... не потому-ли что он а) быстрее б) имплементировал в железе инструкциями типа AES-NI?

Опять вы производительность оптимизируете?

Причём тут сравнение gql vs sql?

а ты наверх полистай, там человек утверждал мол зачем GQL если есть SQL

Опять вы производительность оптимизируете?

я лишь оспариваю твоё утверждение о том что асимметричное шифрование это якобы "проще, быстрее и надёжнее"

а ты наверх полистай, там человек утверждал мол зачем GQL если есть SQL

Мне это зачем? Я сказал, что судя по твоим высказывания ты не знаешь, что такое sql. И причём здесь gql и человек что то утверждающий? Хотя я подобных утверждений не видел, скорее это твоя трактовка

Помогите. Использовал Sublime, стоял GoSublime, Потом перестал работать автокомплит. GOPATH по советам в интернете вроде поставил, но ничего не поменялось.

ERROR: S client not available

Мне это зачем? Я сказал, что судя по твоим высказывания ты не знаешь, что такое sql. И причём здесь gql и человек что то утверждающий? Хотя я подобных утверждений не видел, скорее это твоя трактовка

по каким высказываниям то?)) ну что-за обвинения такие)))

Помогите. Использовал Sublime, стоял GoSublime, Потом перестал работать автокомплит. GOPATH по советам в интернете вроде поставил, но ничего не поменялось.

"вы пробовали выключить и снова включить"? переустанови))

"вы пробовали выключить и снова включить"? переустанови))

Переустанавливал gosublime или сам редактор тоже?

айда linux снесу

по каким высказываниям то?)) ну что-за обвинения такие)))

Не обвинение, а предположение. Сообщение выше про базу выставленную наружу

Не обвинение, а предположение. Сообщение выше про базу выставленную наружу

и чего неверного в том, что бд нельзя шарить в публичную сетку?

и чего неверного в том, что бд нельзя шарить в публичную сетку?

То что sql это не база

То что sql это не база

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

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

Ну вот либо ты не понял человека, либо не знаешь что такое sql.

Ну вот либо ты не понял человека, либо не знаешь что такое sql.

о боже, давайте завершать этот нонсенс

о боже, давайте завершать этот нонсенс

Боже тут ни причём) нонсенса тоже нет, просто ты при недостаточной компетенции весьма вольно трактуешь чужие слова не до конца понимая их) Но да, завершим это.

я лишь оспариваю твоё утверждение о том что асимметричное шифрование это якобы "проще, быстрее и надёжнее"

Чтобы оспаривать - надо потрудиться понять, для начала

Боже тут ни причём) нонсенса тоже нет, просто ты при недостаточной компетенции весьма вольно трактуешь чужие слова не до конца понимая их) Но да, завершим это.

я попрошу оставаться на уровне темы, а не спускаться на уровень личностей. я человека понял, но он не понял GQL. ещё раз повторюсь, что 2 возможных варианта использования SQL в сервер-клиент коммуникации: 1. SQL как язык API 2. SQL как язык прямого обращения к публичной БД очень плохие варианты. очень. во втором варианте большие проблемы безопасности. а в первом варианте просто нет смысла. query { customer(id: "xyz") { friends(ageRange: 18_to_25) { name employer { name } } } } напишите подобный запрос в SQL... а потом напишите движок, который способен будет этот SQL пропарсить, проверить, валидировать и... разница GQL и SQL станут очевидны

я попрошу оставаться на уровне темы, а не спускаться на уровень личностей. я человека понял, но он не понял GQL. ещё раз повторюсь, что 2 возможных варианта использования SQL в сервер-клиент коммуникации: 1. SQL как язык API 2. SQL как язык прямого обращения к публичной БД очень плохие варианты. очень. во втором варианте большие проблемы безопасности. а в первом варианте просто нет смысла. query { customer(id: "xyz") { friends(ageRange: 18_to_25) { name employer { name } } } } напишите подобный запрос в SQL... а потом напишите движок, который способен будет этот SQL пропарсить, проверить, валидировать и... разница GQL и SQL станут очевидны

Причём тут разница gql vs sql? Ты вот говоришь, но сам не слышишь)

Причём тут разница gql vs sql? Ты вот говоришь, но сам не слышишь)

и что я не слышу?

и что я не слышу?

То что речь не про gql

Зачем какой-то новый язык запрос изобретать.

@snipnick это относилось к GQL

@snipnick это относилось к GQL

Ну так ты мне приводит доводы gql vs sql, а я их не сравнивал, я сделал предположение о твоём понимании что такое sql

Ну так ты мне приводит доводы gql vs sql, а я их не сравнивал, я сделал предположение о твоём понимании что такое sql

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

Коллеги, хватит

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

Обоснование выше

Договориться вы не сможете

Коллеги, хватит

ну нельзя ставить под вопрос компетентность человека без обоснований, это равносильно унижению, некрасиво и неправильно

Зацепились за слова и понеслось))

Хотите продолжать - идите в личку

ну нельзя ставить под вопрос компетентность человека без обоснований, это равносильно унижению, некрасиво и неправильно

Дуэльный кодекс на подходе :)

это-ж портит атмосферу чата и сообщества, я считаю это недопустимым

Помогите. Использовал Sublime, стоял GoSublime, Потом перестал работать автокомплит. GOPATH по советам в интернете вроде поставил, но ничего не поменялось.

В общем, переход Go на другую модель пакетов поломал gocode и пока какие-то странные решения.

В общем, переход Go на другую модель пакетов поломал gocode и пока какие-то странные решения.

ты про vgo?

Наверное. С Go 1.11 написано

Если интересно, https://margo.kuroku.io/b/migrate/?_r=gs

Надо новый редактор искать, у Sublime вечные проблемы(