Существуют ли технологии взаимодействия десктопа и веба на стороне клиента кроме Java?

Question

[kealman]

Коллеги, вот в чем вопрос. Существуют ли технологии взаимодействия десктопа и веба на стороне клиента кроме Java? В частности, можно ли проверять достоверность пользователя, пытающегося авторизоваться при помощи десктоп приложения? Интересует именно прямое взаимодействие, грубо говоря, браузер <-> приложение. Спасибо

Comments

[kealman]

Ответ товарища @zxspectr подтолкнул меня на мысль взаимодействовать через сокеты. Как думаете это возможно и какие подводные камни могут быть?

[kealman]

Прошу прощения, плохо сформулировал вопрос и меня не правильно поняли. Немного уточнения. Десктоп приложение является как дополнительная защита при авторизации на сайте. Т.е. само приложение должно взаимодействовать например со страницей авторизации и передавать туда дополнительную информацию

Answer 1

[Григорий]

Посмотрите в сторону REST API, может подойдёт.
Проверку можно реализовать на токенах. Передавая его при запросах.
api.mail.ru/docs/guides/restapi

Comments

[kealman]

Спасибо за ответ. Не много не понял как именно взаимодействовать таким образом. Поднять на десктоп приложении веб сервер?

[Григорий]

@kealman С сокетами у вас могут быть проблемы по части соединения, если оба приложения сидят за серым IP.
А взаимодействие происходит путём отправки POST, GET запросов. Их можно слать сразу из приложения, без помощи браузера.

[Григорий]

@kealman На каком языке вы хотите писать приложение?

[kealman]

@zxspectr Писать планирую на c#. Насчет реста, просто в идеале хотелось бы чтобы все это работало на машине у клиента и видимо я как-то не правильно думаю, но я не могу понять как тут работать с рестом, кроме как на десктоп приложении у клиента поднимать веб сервер, по которому будет общаться js клиент из браузера, да и при таком подходе мы сталкиваемся с тем что кроссдоменный ajax нельзя :( . Идея с сокетами заключается в том, чтобы через веб сокет создавать tcp соединение именно с js клиента на десктоп приложение по localhost. И в случае авторизации по десктоп приложения получается такая схема. Пользователь открывает страницу, js по websocket цепляется по localhost и какой-нибудь порт на десктоп приложение, проверяет есть ли соединение, если есть, то начинаем принимать данные о авторизации и т.п.

Answer 2

[Алексей Сундуков]

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

Comments

[kealman]

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

[Алексей Сундуков]

@kealman смысл? Исходя из текущего описание все эти манипуляции приложение-браузер-сервер видятся большим и главное ненужным усложнением.

Answer 3

[Алексей Сундуков]

@kealman

браузер <-> приложение.

Нафига? Если приложение может устанавливать сетевые соединения, то оно сразу должно ходить на сервер.

Answer 4

[Тимур]

Зачем для авторизации еще какое-то приложение? Лучше тогда усложните алгоритм авторизации на сервере. Но зачем огород городить. У вас получается странная схема: клиент> клиент> сервер. Притом непонятно как вы из веб клиента собираетесь проверять наличие апликашки на компьютере - апплет прикрутите? Существует проверенная схема : клиент - сервер. Пусть клиентом будет что-то одно либо десктоп приложение, либо веб- клиент. Имхо конечно.

Comments

[kealman]

@timych дело в том, что требуют чтобы аккаунт был привязан к конкретной машине. И кроме как чтобы юзер ставил доп. ПО, пока нет идей

[Тимур]

Хм тогда не знаю, может в сторону MAC -адреса как-то копать.

[Тимур]

Кстати может тогда действительно апплет прикрутить? Можно mac пробить и аппликашка будет запускаться только при открытии веб страницы.

[kealman]

@timych получается java машину все равно ставить придется. Лучше уж тогда свое ПО, с бизнес стороны лучше выглядеть будет.