Страницы

Поиск по вопросам

Показаны сообщения с ярлыком авторизация. Показать все сообщения
Показаны сообщения с ярлыком авторизация. Показать все сообщения

суббота, 11 апреля 2020 г.

Python 3 авторизация

#python #авторизация

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

вот первый, тут просто выводится неавторизованная страница

import requests
from requests.auth import HTTPDigestAuth
url = 'https://passport.yandex.ru/auth?retpath=https%3A%2F%2Fmoikrug.yandex.ru'
r=requests.get(url, auth=HTTPDigestAuth('Мой логин', 'Мой пароль'))
print(r.text)


вот второй способ, тут ошибка

import urllib.request
import http.cookiejar
import urllib.parse

cookieJar = http.cookiejar.CookieJar
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cookieJar))
params = urllib.parse.urlencode({'login' : 'Мой логин',
                       'passwd' : 'Мой пароль'})

#get = urllib.request.Request('https://passport.yandex.ru/auth?    retpath=https%3A%2F%2Fmoikrug'
#            '.yandex.ru' , params)

f = opener.open('https://passport.yandex.ru/auth?retpath=https%3A%2F%2Fmoikrug'
        '.yandex.ru', params)
h = f.read()
print(h)


Выводит ошибку:

line 14, in 
   '.yandex.ru', params)
TypeError: POST data should be bytes or an iterable of bytes. It cannot be of type str.


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


Ответы

Ответ 1



Во втором случае ошибка связана с тем, что вы пытаетесь вызвать метод open с аргументом params, который является строкой, а методу нужен аргумент типа байт или коллекция байт. Вам должна помочь следующая конструкция: params = params.encode('UTF-8') А вообще, я бы не советовал работать с сайтом moikrug.ru таким образом. У сайта есть API и документация к нему. Используйте её, это будет наиболее правильным решением.

четверг, 9 апреля 2020 г.

Авторизация на поддомене

#php #javascript #авторизация

                    
Видел как некоторые сайты используют поддоменную авторизацию. То есть, например,
на поддомене login.example.com вешают куки, а уже на    example.ru/* проверяют... не
понятно, при каждом действии нужно переадресовывать на login.example.com и проверять??
Если нет, то как это происходит? И почему разработчики прибегают к поддоменной авторизации?
    


Ответы

Ответ 1



Дело в том, что стандарт мета-данных кукисов позволяет выставить разрешение на домен 2-го уровня и его поддомены, причём на все сразу .site.com (эквивалент *.site.com), а не на конкретный, т.е. нет возможности через запятую или как-то иначе указать список всех доменов на которых требуется авторизоваться. Выхода два, делать редирект на каждый, передавая идентификатор сессии, либо иметь единую точку авторизации - некий proxy-домен. Т.е. всё сводится к тому, чтобы передать идентификатор сессии на все желаемые домены/поддомены. Алгоритм прост. К примеру: Заходим в первый раз на сайт site.com - кук нет Происходит почти незаметный редирект на login.site.com и если куки нет, то генерируем сессию и устанавливаем куку на login.site.com. Перередирект на site.com с идентификатором сессии в параметре URL-а (site.com?sid=<хеш>). Уставнавиливаем куку с данным идентификатором для site.com. Чтобы избавиться от идентификатора сессии в параметре URL-а делаем рефреш (т.е. редирект на site.com но уже без параметра). Данная манипуляция необходима исключительно для безопасности, чтобы, к примеру, случайно не засветить идентификатор в referer, ибо пользователь может после авторизации перейти по ссылке на какой-нибудь сторонний сайт. Кука установлена. Как только кука или сессия протухнет/будет удалена, вновь всё это повторится. Далее, допустим мы зашли на foo.site.com - кук нет. Происходит редирект на login.site.com - кука есть. Перередирект на foo.site.com с идентификатором сессии ... Таким образом, именно login.site.com хранит базовую куку с идентификатором сессии (вернее, хранилищем выступает кеш вашего браузера) и раздаёт её через редирект доверенным доменам/поддоменам. Преимущество данного подхода в том, что можно создать единых хаб авторизации для доменов 2-го уровня. К примеру, google.com и youtube.com

Ответ 2



Так делают чтобы разгрузить основной сервер от авторизаций, особенно если авторизация сложная. Перенос кук используйте. php session_set_cookie_params(0, '/', 'www.example.com'); session_start(); .htaccess php_value session.cookie_domain .example.com Например у моего товарища авторизация проходит через супер-пупер криптосамописный хеш. и время доходит до полусекунды причем сильно грузит серв. поэтому для авторизации стоит отдельный серв, которому не страшны такие проседания.

пятница, 13 марта 2020 г.

Используются ли в современных веб-проектах Basic и Digest аутентификации?

#авторизация #аутентификация


Я в них не сильно разбираюсь, поэтому мое мало информированное мнение пока стоит
на позиции, что они почти никогда не пригодятся, и если нужно будет создавать легкий
или средний веб-проект, то алгоритм аутентификации и авторизации пользователей и админов
будет целиком на плечах веб-разработчика, и скорее всего так все делают?
    


Ответы

Ответ 1



Для начала, давайте разберемся как работают перечисленные вами механизмы аутентификации. При HTTP Basic аутентификации вместе с каждым HTTP запросом вместе с заголовками передается связка логин/пароль, которые позволяют однозначно аутентифицировать пользователя. HTTP Digest аутентификация похожа на HTTP Basic, но вместо связки логин/пароль передается контрольная сумма, вычисленная на основе параметров запроса (метода, URI, иногда тела запроса), логина, пароля и, возможно, еще нескольких дополнительных параметров. (Часто используется уникальный для каждого запроса параметр nonce, препятствующий выполнению атаки на повторение запросов.) Если говорить о других типах аутентификации, то чаще всего web-приложения используют аутентификацию на базе Cookie. Пользователь передает логин/пароль на сервер, сервер проверяет эти данные и в случае успеха отдает пользователю заголовок Set-Cookie с идентификатором пользовательского сеанса. При всех последующих запросах пользователь передает посредством Cookie этот идентификатор, который и используется для аутентификации. Принципиальная разница между первыми двумя методами и последним заключается в том, что для механизмов HTTP Basic и HTTP Digest серверу не нужно хранить сессионные данные пользователей (идентификатор пользовательской сессии). При таком подходе, каждый HTTP запрос содержит всю необходимую для построения ответа информацию и может быть изолирован от предыдущих/последующих запросов. Идея сервера, не хранящего состояние пользовательских сессий лежит в основе довольно популярного RESTful подхода. Этот подход часто используется для построения серверного API. И да, говорить, что HTTP Basic/Digest не используется в современных web-проектах -- неверно. Тут все зависит от сложности, целей и задач проекта. Замечание: Важно понимать разницу между аутентификацией и авторизацией. Под аутентификацией обычно понимают процесс определения того, что пользователь является именно тем, кем он представился. Под авторизацией обычно понимают проверку полномочий конкретного, уже аутентифицированного, пользователя на выполнение некоторых действий в системе. Выше были указаны только методы аутентификации. Построение правильного механизма авторизации пользователей все равно лежит на плечах разработчика.

Ответ 2



Для аутентификации непосредственно пользователей Basic и Digest аутентификация используются редко. Обычно после отправки логина/пароля и их валидации пользователю прописывают SESSIONID в cookies и в дальнейшем используют именно его. Однако при работе с клиентами API оба вида аутентификации достаточно широко используются. Тут можно либо просить клиента передавать Basic/Digest токен с каждым запросом, либо использовать Basic (реже Digest) аутентификацию для выдачи токена OAuth. При этом важно помнить, что использовать Basic аутентификацию на незашифрованном соединении нельзя, ведь логин и пароль передаются в открытом виде.

вторник, 25 февраля 2020 г.

Алгоритм регистрации и авторизации через социальные сети

#oauth #php #vkontakte_api #авторизация #регистрация


Добрый вечер.
Расскажите, пожалуйста, как организовать сабж. Что хранить в базе, что держать в
куках и как организовать авторизацию. Можно без кода - на словах. На всякий случай
- пишу на PHP.
Заранее спасибо.    


Ответы

Ответ 1



Пришёл новый чел, авторизуете его через ВК (см. Виджет Авторизации), получая от ВК напрямую в ваш сервер подтверждение, что этот клиент действительно Вася с ID 12345. Генерите для Васи запись у себя в БД, в том числе некий уникальный ключ, а ему ставите куки с этим ключем. В следующий раз придёт - если есть куки, соотв. записи в вашей БД - это видимо, Вася.

Ответ 2



Воспользуйтесь уже готовыми решениями, например http://ulogin.ru/constructor.php На странице справки, в разделе "Настройки виджета" -> "Информация о пользователе" найдете все данные, которые можно выудить из соц сети про данного пользователя, от имени, почты, до пола и возраста (если конечно есть такие). Дальше - как при обычной авторизации через логин форму - ставите куку после авторизации, и понеслась. Или делаете что-то типа авторегистрации (минимально необходимые данные уже ведь есть) и если чего-то нехватает, можете перебрасывать пользователя на профиль и пусть дозаполняет то, что осталось в неведении. При этом, раз пользователь фактически не вводит пароль, то можно ему сгенерить какой-нибудь достаточно стойкий из вида "!k2j$4#(Dk)543\bls"

Авторизация на сайте: ключевые моменты

#веб_программирование #авторизация


Понимаю, что по теме авторизации на просторах интернета море информации, но всё таки
решусь задать один вопрос. Без каких ключевых моментов нельзя обойтись, делая регистрацию
на своём сайте? Авторизация через сессии. Задавая этот вопрос, рассчитываю на ответ
примерно вот в таком виде:


Пароль в базе данных хранить в зашифрованном виде.
При авторизации сохранять время логина, IP и т. д.
Проверка залогинен/нет должна проводиться не только как isset($_SESSION['username']),
а.. А кстати, как это делать?


P.S. Нет, меня не забанили в поисковых системах, но я хочу услышать на словах, что
нужно делать, а не разбираться в тоннах чужого кода, гадая, зачем же он нужен.. 
Спасибо.^^
UPD: тем не менее кто может вкратце дать ответ на вопрос, как же начинающему, но,
я надеюсь, перспективному проекту реализовать авторизацию на сайте?
UPD: вопрос закрыт, в связи с отсутствием новых записей. Надеюсь кто-нибудь подчеркнет
из всех этих дискуссий нечто полезное для себя)    


Ответы

Ответ 1



Давайте я пока попробую обобщить, что у нас получилось, а дальше как получится, может кто-то представит нам другой вариант.. Итак, поехали, некоторые общие выводы: Авторизация с помощью сессий не годится, так как она не будет работать, если сайт физически находится на нескольких серверах (сам не знаю, но так сказал @BOPOH). Соответственно если мы рассчитываем, что наш сайт будут любить тысячи людей, надо сразу выбирать другой способ. Исходя из первого, начинаем искать другую реализацию. Так вариантов много, были предложены варианты с БД и memcache.(опять же ВОРОН'ом). Я для себя решил, что сейчас буду делать через базу данных, просто потому, что для меня на данный момент это проще(я же только начинаю постигать азы вебдева). Как же сделать авторизацию через бд? Очевидно, алгоритм, упрощённый до минимума таков: Пользователь вводит логин и пароль, пароль сравнивается с паролем на сервере, если они одинаковы, в специальную таблицу заносятся данные о текущем логине. Пока точно не знаю, какие именно данные понадобятся, но я так думаю что это будут: IP-адрес пользователя, время логина, уникальный ключ данной сессии(отныне употреблять это слово я буду в значении "процесс пребывания пользователя на сайте в залогиненном состоянии", $_SESSION тут уже не при чём). Этот же ключ будет заноситься в cookies. Далее при загрузке каждой страницы браузер будет обращаться к серверу по этому ключу, и оттуда возвращать данные о логине. Теперь о безопасности. Естественно, в базе данных не может храниться сам пароль, а должен храниться только его хеш, то есть зашифрованная неким алгоритмом(лучше без возможности дешифровки) строка. Самый распространённый пример - функция md5(). Только желательно использовать её в таком виде: md5($pass.$salt), так как существует куча сайтов-дешифровщиков обычных md5-строк. Далее со слов @avp: ключ должен перевычисляться независимо сервером и клиентом при каждом обмене. И сервер сравнивает присланный клиентом ключ с ожидаемым. Также для важной информации хэш пароля пересылать по сети нельзя. И еще, желательно как-то проверять, что сервер с которого Вы получили картинку на экран - это не подстава. Решение о необходимости использования этих советов, а также способы реализации оставлю за вами, уважаемые rодеры. Для себя выберу первые два пункта(мой и первый пункт @avp). Дополняйте меня)

Ответ 2



(я же только начинаю постигать азы вебдева) Если вы начинающий WEB-разработчик, советую не заморачиваться с всеми возможными session handler'ами.. Используйте стандартную работу сессий (через куки). В случае, если куки будут отключены, то PHP сам изменить поведение сэссия (через GET параметр). Непосредственно по поводу вашего вопроса: 1. С точки зрения безопасности, лучше пароль хранить зашифрованным. Но при таком подходе, если пользователь забудет пароль, вы не сможете ему напомнить его старый пароль. вам прийдется генерировать новый. 2. При авторизации сохраняйте любую нужную вам информацию.. Это может быть не только время и ip, а также и referer (т.е. с какого сайта пользователь пришел к вам на сайт) Тут никаких ограничений, лишь ваш полет фантазий )) 3. Для большинства случаев, вполне хватает проверки if(isset($_SESSION['is_auth']) and $_SESSION['is_auth'])... Со временем, когда вы "подрастете" в плане программирования, можно будет заглянуть как сделана аутентификация у "больших".. К примеру Security Component в Symfony

понедельник, 24 февраля 2020 г.

Авторизация пользователя vk с помощью cURL (PHP)

#php #вконтакте #curl #авторизация


Добрый день.

Необходимо авторизировать пользователя vk с помощью PHP скрипта и библиотеки cURL. 
Были рассмотрены следующие решения:


https://forum.antichat.ru/threads/426901/
http://sauron.org.ua/post/938


На основе решений были составлены следующие скрипты.

Получение значений lg_h и ip_h (работает, получает):

$url = 'http://vk.com';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT
6.1)");
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
        'content-type: application/x-www-form-urlencoded',
        'origin: http://vk.com',
        'referer: http://vk.com/',
));
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

$content = curl_exec($ch);

preg_match_all("/name=\"ip_h\" value=\"(.*?)\" \\//s", $content, $ip_h);
preg_match_all("/name=\"lg_h\" value=\"(.*?)\" \\//s", $content, $lg_h);


Отправка запроса авторизации вида:

http://login.vk.com/?
act=login&
role=al_frame&
_origin=http://vk.com&
ip_h=$ip_h&
lg_h=$lg_h&
email=&
pass=


Сам скрипт:

$url = 'http://login.vk.com/?act=login';
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0)
Gecko/20100101 Firefox/42.0");
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
//curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_POST, true);

$data = array(
    'act' => 'login',
    'role' => 'al_frame',
    '_origin' => 'http://vk.com',
    'ip_h' => $ip_h[0][1][0],
    'lg_h' => $lg_h[0][1][0],
    'email' => '',
    'pass' => ''
);

curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));

curl_setopt($ch, CURLOPT_HTTPHEADER, array(
    'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
    'content-type: application/x-www-form-urlencoded',
    'origin: http://vk.com',
    'referer: http://vk.com/',
));

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);

curl_setopt($ch, CURLOPT_COOKIEJAR, '/home//Development/vk/cookie.txt');
curl_setopt($ch, CURLOPT_COOKIEFILE, '/home//Development/vk/cookie.txt');

echo curl_exec($ch);


На выходе получаю следующее содержимое страницы:




В свою очередь куки принимают следующие значения:

Set-Cookie: remixmid=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixsid=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixsid6=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixgid=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixemail=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixpass=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixapi_sid=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/;
domain=.vk.com
Set-Cookie: remixpermit=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com
Set-Cookie: remixsslsid=DELETED; expires=Thu, 01 Jan 1970 00:00:01 GMT; path=/; domain=.vk.com


Смею предположить, что не удается передать значение email, т.к. в коде JS именно
на это и ошибка. При ручном составлении URL и перехода по нему — успешное возвращение
хэша и содержимое страницы следующее:




Авторизация проходит успешно. После доступен профиль пользователя.
    


Ответы

Ответ 1



Только что написал рабочий код авторизации во ВКонтакте — http://pastebin.com/5YecKuUs Только учтите, каптча не поддерживается, поэтому сами уже её добавьте. Тест успешно пройден на моём тестовом аккаунте ;)

Ответ 2



Есть рабочая библиотека для PHP, которая получает куку remixsid.

Ответ 3



По состоянию на июль 2018 это рабочий код. Авторизация через мобильную страницу т.к. проще. $email = "{ТЕЛЕФОН}"; $pass = "{ПАРОЛЬ}"; $auth_url = "https://m.vk.com"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $auth_url); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0); //файл для сохранения кукис - cookie.txt curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookie.txt'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); //получаем содержимое формы авторизации (URL атрибута action) $login_page = curl_exec($ch); curl_close($ch); //парсим страницу... $html = str_get_html($login_page); //..и узнаем урл авторизации (использовал библиотеку Simple PHP DOM Parser) $login_url = $html->find("form",0)->action; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $login_url); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0); //отправляем ПОСТ запрос curl_setopt($ch, CURLOPT_POST, 1); //следуем за редиректом curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); //данные запроса curl_setopt($ch, CURLOPT_POSTFIELDS, ["email"=>$email, "pass"=>$pass]); //СНАЧАЛА ЧИТАЕМ КУКИ полученные в первом запросе curl_setopt($ch, CURLOPT_COOKIEFILE, 'cookie.txt'); //потом ДОБАВЛЯЕМ НОВЫЕ curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookie.txt'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_exec($ch); curl_close($ch); //пользователь авторизован //далее тестируем $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://vk.com/groups?act=catalog"); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); //только читаем куки curl_setopt($ch, CURLOPT_COOKIEFILE, 'cookie.txt'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $page = curl_exec($ch); curl_close($ch); //если ваш сервер работает на UTF-8, в отличие от VK (windows-1251) echo iconv('windows-1251','utf-8',$page);

Ответ 4



Попробуйте закодировать функцией urlencode

четверг, 13 февраля 2020 г.

Выполнение персональных действий без регистрации

#авторизация


Недавно увидел интересную, но очень простую реализацию (пока выдавать не буду).
Есть сайт, есть некоторые действия (например создание тикета, возможно запись в записной
книге) и есть пользователь. 
Вопрос как правильно организовать авторизацию без регистрации пользователя (т.е.
никаких форм регистрации и паролей).
Если не понятно спрашивайте, постараюсь более понятно объяснить вопрос.    


Ответы

Ответ 1



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

Ответ 2



А таким образом не увеличится возможность потери личных данных, информации?

Ответ 3



куки +, возможно, ip. При подключении пользователя проверяем, есть ли куки с UID? Если есть, значит пользователь у нас не в первый раз, предоставляем ему возможности, связанные с UID. Если UID не найден - генерируем новый UID, устанавливливаем куки. Вуаля. У нас новый "зарегистрированный" пользователь... Только две проблемы: а. Обозреватель пользователя может не поддерживать куки/либо они могут быть отключены. б. пользователь может сам потереть свои куки тем самым "потерЕв" "регистрацию"...

Ответ 4



Выдать пользователю уникальный идентификатор, записать в куки. Чтобы пользователь не смог потереть куки, пишем синхронизатор между "флеш куками" и обычными куками на ActionScript и на JavaScript. Синхронизируем их раз в секунду (можно и несколько раз в секунду), в результате шанс потерять куки в разы уменьшается, особенно на тех браузерах где одновременно потереть стандартный куки и "куки флеша" не возможно. Материал по теме: Local Shared Objects — Флеш куки JFStorage: Альтернатива cookies

Ответ 5



Можно совместить всё в одной форме. Быстро и просто.

воскресенье, 9 февраля 2020 г.

UHF RFID. Телефоны

#android #авторизация #terminal


Прочел в интернете, а причем тут, что на телефонах с ОС Андроид(2.3 или выше) поддерживается
сканирование RFID меток. Является ли это истиной ? :D. 
Спрошу вот так: Есть телефоны в которых есть RFID считыватель.  
    


Ответы

Ответ 1



В статье по вашей ссылке речь идет о конкретных моделях внешних считывателей RFID-меток, которые взаимодействуют со смартфоном через Bluetooth и Wi-Fi. *Bluetooth and Wi-Fi. BLE support for idChamp RS3, Scanfob® NFC-BB2-BLE and more (Android 4.3+ needed for BLE support) Однако, телефон оснащенный NFC-модулем может считывать некоторые RFID-метки диапазона HF (13.56 МГц, стандарт ISO 14443). UHF RFID метки работают на совершенно других частотах (860—960 МГц). Их вам считать НЕ удастся.

воскресенье, 26 января 2020 г.

RFID считыватель на планшете?

#android #авторизация #terminal


Стоит задача - сделать терминал для ввода данных на планшете(Android), чтобы была
идентификация пользователя, который вводит данные. Если проще, то примерно так: подходит
человек к терминалу (стойка с закрепленным в специальном корпусе планшетом), прикладывает
свою rfid карточку, планшет разблокировывается, и человек на планшете отмечает, выполненное
задание. Эту информацию (какое задание сделано и кем сделано) планшет отправляет на сервак.

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

Пофиг на начинку - приложение для андроида можно будет написать. Я имею в виду конструкцию.
Стойка+планшет+считыватель, и чтобы все это было на постояной запитке. Гугл что-то
мне не очень помог в моем поиске.
    


Ответы

Ответ 1



Здравствуйте! Авторизоваться на Android-девайсе можно с помощью поддержки его NFC-технологией. Осталось только найти нужный девайс.

среда, 22 января 2020 г.

Не проходит запрос к БД при авторизации PHP + MSSQL

#php #sql_server #pdo #авторизация


Столкнулся со следующей проблемой: не проходит запрос БД. Данные получаю с форм посредством
AJAX (запаковываю в JSON и отправляю на сервер). Далее, используя PDO в PHP подключаюсь
к MSSQL, где находится БД. На сервер данные приходят, а к БД запрос не выполняется.

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    print("Couldn't connect to the database".$e->getMessage());
}

$user = json_decode($_REQUEST['user']);

$user->password = hash('md5', $user->password);


$query = $db->exec("SELECT * FROM dbo.Users WHERE Login = '".$user->login."' AND
Password = '".$user->password."'") or die("Query error");
var_dump($query);
if ($query==1) {
   $cookie_name = $user->login;
   $cookie_value = $user->password;
   setcookie($cookie_name, $cookie_value, time() + 3600);
}?>


Подскажите, пожалуйста, что делать. Пытался использовать одинарные кавычки для переменных
и функцию query(), которая возвращает строку запроса.
    


Ответы

Ответ 1



Проблему решил использованием функции prepare() $query = $db->prepare('SELECT * FROM dbo.Users WHERE Login = ? AND Password = ? ') or die("Query error"); $query->execute(array($user->login, $user->password)); $res = $query->fetchAll(); if ($user->login == $res[0][1] && $user->password == $res[0][3]) { $cookie_name = $user->login; $cookie_value = $user->password; setcookie($cookie_name, $cookie_value, time() + 3600); } var_dump($res);

воскресенье, 12 января 2020 г.

Авторизация и сессии [закрыт]

#веб_программирование #php #пароль #сессия #авторизация


        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
                        
                        Закрыт 4 года назад.
                                                                                
           
                
        
Подскажите, как в наше время делают авторизацию и где хранят сессии. Давно не занимался
сайтами, возможно отстал от прогресса.
Собственно:

Храню пароль в виде md5($salt.$pass.$salt). Вроде их уже легко ломают?
sessionhash=md5(uniqid(microtime()));
Сессии хранятся в таблице MySQL в sissionid, userid, sessionhash
sissionid и sessionhash отдаются в куках.

Как сейчас это делается?    


Ответы

Ответ 1



Данные, хранящиеся на стороне пользователя, надо зашифровать ключом, хранящимся на сервере. Тут это разбирается на примере Node.JS и для PHP: Раз и Два

Ответ 2



По пункту 1: В настоящее время существуют очень эффективные реализации перебора хэшей. Поэтому даже длинные пароли, подвергнутые однократному хэшированию, перестали быть безопасными. В версии php 5.5 реализован алгоритм PBKDF2. Его рекомендууется использовать для получения устойчивых хэшей. http://php.net/manual/ru/function.hash-pbkdf2.php.

Ответ 3



Советую посмотреть в сторону фреймворка CodeIgniter. Всё удобно, защищено и очень просто. + Есть библиотека аутентификации и регистрации.

четверг, 9 января 2020 г.

Различия OAuth и OpenID

#авторизация #oauth #аутентификация #oauth2 #openid


Скажите, пожалуйста, чем отличаются OAuth и OpenID?
    


Ответы

Ответ 1



OpenID позволяет сайту удостовериться, что его пользователь владеет неким персональным URL (своим сайтом, блогом, профилем). Этого факта достаточно для того, чтобы использовать уникальный URL для узнавания того же самого пользователя в следующий раз. И всё. Все остальные вещи — заведение аккаунта, получение email'а и других данных, разрешение какой-то активности на сайте — остаётся на усмотрение сайта. Другими словами, OpenID — это чистая аутентификация: вы знаете, кто к вам пришёл, но вольны делать с этим знанием всё, что угодно. OAuth позволяет программе (на вебе или локальной) получить от пользователя права на использование какого-то конкретного API. Права обозначаются токеном, свойства которого никак не определены: он может быть одинаковым для разных пользователей, может быть разным для одного в разное время. Всё, что гарантируется — это что программа в обмен на токен сможет выполнять какие-то действия на каком-то сервисе. Другими словами, OAuth — это чистая авторизация: вы обладаете конкретными правами, но не можете в общем случае по ним определить, кому они принадлежат. Аналогия. OpenID — это ваш паспорт: он говорит, кто вы, но что он даёт, зависит от места, куда вы с ним пришли. OAuth — ключи от вашей машины: с ними можно ездить на вашей машине, даже не зная, как вас зовут. Разница между OpenID и OAuth - Иван Сагалаев

суббота, 4 января 2020 г.

Как сделать авторизацию на сайте в android приложении с помощью Jsoup

#java #android #post #авторизация #jsoup


Большая просьба не кидать камнями а написать по делу либо скинуть ссылку на уже готовые
гайды по созданию авторизации на сайте. Перерыл весь гугл - ничего рабочего так и не
нашел(Руки не из заднего места) сам по себе начинающий кодер на java, но структуру
кода понимаю(Что, где и от чего зависит). Нужен готовый пример с рабочим пост запросом,
единственное из того что нашел хоть как то давало признаки жизни.

try {
    Connection.Response res1 = Jsoup.connect("http://site.ru")
            .data("login","admin")
            .data("passwd","admin")
            .data("send","Войти")
            .method(Connection.Method.POST)
            .execute();
    Map loginCoockies = res1.cookies();
    System.out.println(loginCoockies);
    Document doc = Jsoup.connect("http://site.ru")
            .cookies(loginCoockies)
            .get();
    System.out.println(doc);
} catch (IOException e) {
    System.out.println(e);
}
return null;


После запуска выдает: 


  {PHPSESSID=t7idbm5jkr40ial25brvju72n2} 


и html код страницы.

Точнее после каждого нажатия на кнопку выдает PHPSESSID=(Всегда разный). Страница
html кода показывает что я так и не был авторизован.
    


Ответы

Ответ 1



Разобрался сам, авторизация проходит успешно, проверка тоже. Скачал HTTP Analyzer и посмотрел какие данные отправляются POST запросом и куда. Добавил в запрос недостающих данных, и все заработало )

четверг, 2 января 2020 г.

Сохранение пароля браузером при Ajax авторизации

#ajax #авторизация #пароль


Добрый день. Так получилось, что авторизация у меня происходит так:
Пользователь вводит данные, и при нажатии кнопки "вход" информация обрабатывается
через ajax-запрос. При удачном логине страница просто обновляется.
При таком подходе браузер не запоминает пароли(я имею в виду эти окошечки "сохранить
пароль?").. А я хочу, чтоб сохранял, функция-то удобная.
Какие бы костыли сделать?    


Ответы

Ответ 1



Я задавал такой же вопрос на Хабре и получил отличный ответ: 1. Сделайте себе фейковый адрес который ничего не делает и возвращает 200 ответ 2. Форме укажите этот фейковый адрес и _target=«iframe_name» (естественно фрейм должен быть) 2. Перед аяксовой отправкой данных на правильный адрес, делайте реальный сабмит формы. 3. Логиньтесь аяксом, смотрите как браузер спрашивает не запомнить ли логин/пароль 4.!!! 5. PROFIT!

Ответ 2



Только с использованием iframe (пример). Потому что в AJAX-форме вы отменяете действие submit и посылаете ajax-запрос. А браузер запоминает данные только при успешной отправке формы классическим методом.

Ответ 3



Можна пошаманить вот так:
JS код: function login(f) { var username = f.username.value; var password = f.password.value; //ajax magic here return false; //or the form will post your data to login.php }

Ответ 4



Часто хватает галочки «запомнить меня». Хранить пароли — это неправильно. Пользователей нужно отучать от этого.

вторник, 24 декабря 2019 г.

Авторизация через социальные сети

#php #авторизация


Всем привет. Хочу реализовать возможность заходить и регистрироваться на сайте через
социальные сети, но появилось несколько вопросов, по поводу реализации данной задумки.
Имеются различные сервисы по реализации этого метода Loginza и uLogin. Они как бы
удобные, но в тоже время нет.
Решил реализовать самостоятельно. У меня уже имеется база с пользователями, где человек
авторизовывается на сайте с помощью е-маил и пароля. 
Стал интересен момент, что если использовать сервисы, то один человек, в зависимости
в сколки соц. сетях он зарегистрирован он может создать зарегистрировать более одного
аккаута, что я бы не хотел.
Пробовал uLogin, вроде все удобно, кроме перечисленного недостатка выше и еще после
регистрационного момента, человека редиректит на мой сайт и передает ему данные для
обработки в POST. Мой сайт реагирует на это, как на попытку атаки csrf. Так же метод
зависит от сервиса, в случаи неполадки функция не будет работать на моем сайте.
Первый вопрос, который я хотел бы узнать: Каким образом производится регистрация,
если у меня уже есть база пользователей, где авторизация по е-маилам? Может ли человек
зарегистрированный на сайте ранее пользоваться авторизацией через соц. сети? 
Если с помощью ВКонтакте авторировываться вручную, то он не дает адрес почты, а если
через uLogin, то есть такая возможность.
Второй вопрос, который я хотел бы узнать: Как предотвратить возможность клонирования
аккаунтов из разных соц. сетей? 
Искал подобную информацию в интернете - не нашел. Если вы нашли, то ссылки будет
достаточно. =)    


Ответы

Ответ 1



Сделайте привязку логинов из соцсетей/openid к аккаунтам на вашем сайте по схеме 1 аккаунт - несколько записей из соцсетей/openid. Если человек авторизовывается через uLogin/Loginzу, привязывать полученный результат к уже существующему аккаунту (сверять по адресу почты) или создавать новый при отсутствии такого имейла в вашей базе. То есть, если на разных логинах соцсетей/openid у человека одинаковый адрес email - при входе через эти разные логины всё-равно получится одна учётная запись на вашем сайте. Ещё, обратите внимание как это сделано на хэшкоде и на многих других сервисах: на странице "Настройки доступа" есть "внешние источники аутентификации для вашей учетной записи". Их может быть несколько, но все они ведут на одну учётку. Тоесть, если рассматривать email как "уникальный" ключ, то можно отследить повторные входы одного человека, тем более что uLogin при входе через вконтактик отдаёт адрес почты пользователя. Насчёт зависимости от сервиса посредника - это да, но вот только без него вам надо будет по отдельности налаживать взаимодействие с каждым из провайдеров авторизации. Можете попробовать сделать какую-нибудь резервную схему - с гуглом/вконтактиком/маилру наладить прямое взаимодействие, и, на случай если uLogin сломается, работать без посредника. Насчёт кода - и uLogin и Loginza предоставляют примеры работы и плагины для популярных cms/фреймворков. Можно скачать и изучить как они устроены.

Регистрация и авторизация через VK API

#php #javascript #vkontakte_api #авторизация #соцсети


Пытаюсь реализовать регистрацию/авторизацию на своём сайте через соц. сеть. 
Не совсем понятен принцип работы и дальнейшая безопасность после авторизации. 

Изучил всё что тут написано: https://vk.com/dev/openapi

Создал приложение, добавил JS VK к себе, добавил тот скрипт, что там прописан. Соединение
проходит, возвращается ID, имя и т.д. (всё что запрошу). Но как мне записать что-нибудь
в БД, чтобы потом определить, что этот пользователь зарегистрирован/авторизован? Никакого
хэша, который я бы мог использовать в этих целях, не возвращается. 

Конечно, я могу после авторизации и получения ответа через JS, отправить AJAX-запрос
к себе на сервер с ответом, который вернул ВК, но как проверить со стороны сервера,
что авторизация прошла успешно и это не злоумышленник подсунул левый ID?

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



Смотрел серию уроков «PHP » Аутентификация через ВКонтакте» и читал другие темы по
этим вопросам, но, в основном, везде рассматривается синхронная авторизация, где пользователь
будет несколько раз перенаправлен на другие страницы сайта, а мне такой вариант не
подходит. Допускаю только одно обновление страницы пользователя: только тогда, когда
он уже авторизован/зарегистрирован. Всё остальное — в асинхронном режиме. 

Опять же, могу отправить ID пользователя к себе на сервер в свой скрипт, но как проверить
его? Ведь у меня не будет параметра code, как в примере по ссылке выше и, соответственно,
я не смогу отправить запрос для получения access_token.



Поправка: параметр code нашёл, а вот параметра redirect_uri — нет, и VK отвечает так:


  {"error":"invalid_grant","error_description":"Code
  is invalid or expired."}


Делаю запрос так:


  $params = array(
    'client_id' => 'тут ид моего приложения',
  
  'client_secret' => 'тут ключ моего приложения', 
  
  'code' => $_POST['user']['sid'], 
  
  'redirect_uri' => '');
  
  $token = json_decode(file_get_contents('https://oauth.vk.com/access_token' . '?'
. urldecode(http_build_query($params))), true);




Понял, что процедуры серверного получения code не избежать. Начал делать по этим
инструкциям: https://vk.com/dev/auth_sites 

Предварительно всё равно провожу клиентскую авторизацию и только при успехе отправляю
запрос на сервер, который затем отправляет запрос для получения переменной code, но
опять вылазит окно с требованием ввести логин/пароль VK (на этот раз его требует серверная
авторизация), а не нормальный ответ. В качестве redirect_uri указываю адрес вызываемого
AJAX-файла, надеясь, что сервер VK вернёт туда $_GET['code'], и следующем запросом
я смогу уже получить access_token...

Я так понимаю, окно с повторной авторизацией вылазит потому, что идёт проверка IP,
которые не совпадают. Как быть? 

Не понимаю, почему бы не сделать один и тот же code-ключ при клиентской авторизации
и при серверной, чтобы можно было связать воедино и добиться-таки доступа в одно обновление
страницы пользователя (с вылезающем окном VK, это ничего), но не 3-4 редиректа, как
предлагается при полностью серверной авторизации в документации. Или, может, что-то
делаю не так (что вероятнее).



Начал в PHP-файле делать так:


  if (!isset($_GET['code']))
  
  header('location:
  http://oauth.vk.com/authorize' . '?' .
  urldecode(http_build_query($params)));
  
  else echo $_GET['code'];


Теперь возвращается code при прямом открытии PHP-файла, а если он вызывается AJAX`ом,
то там, понятное дело, ошибка после редиректа:


  XMLHttpRequest cannot load
  http://oauth.vk.com/authorize...


Попытка использовать cURL или file_get_contents приводит к тому, что возвращается
форма авторизации ВК и начинает "скакать" в прямом смысле слова на экране. 

Эх :( Продолжаю разбираться. Может есть способ отправить запрос VK, но чтобы тот
не редиректил назад, а вернул только ответ? (без redirect_uri сразу возращает ошибку)



UPD

Разобрался почти со всем самостоятельно: пришлось отказаться от авторизации "в один
клик" и смириться с неизбежным — двумя редиректами сначала за code, а потом за access_token.
Теперь другая проблема — как разлогинить приложение у пользователя?

А то получается, после одного подтверждения пользователем всё сохраняется и больше
пользователя уже никто не спрашивает, разрешает ли он доступ сайта к данным, или нет.
С одной стороны — это удобно, но с другой — у пользователя ведь может быть несколько
учётных записей VK, или за одним компьютером могут сидеть несколько человек. 

Поэтому нужно дать возможность разлогинить приложение у пользователя, например, при
переходе по ссылке. Как я понял, это делается по ссылке

http://oauth.vk.com/logout?client_id=ид_приложения 

Но там ещё требует хэш, который непонятно откуда брать: в документации ни слова про
разлогин. Техподдержка вконтакте молчит. Может хоть тут помогут?
Я пытался по-всякому передавать туда и code-переменную из авторизации, и access_token
— толку нет, всё время:


  wrong logout hash

    


Ответы

Ответ 1



Сохраняете авторизацию в сессию, далее просто unlink($_SESSION['Имя сессии']);, всё пользователь разлогинен!

воскресенье, 22 декабря 2019 г.

реализация ЕСИА на сайте

#c_sharp #авторизация #oauth #аутентификация


Добрый день! Встал вопрос прикрутить авторизацию на сайте через есиа (Госуслуги). 
Наверняка кто-то уже проделывал это! Помогите пожалуйста, я от этого очень далека,
а сделать надо...

В общем, имеется сайт на ASP.NET (c#, Windows Forms).

Выбранный тип аутентификации - OAuth 2.0 и OpenID Connect 1.0.

Уже, как указано, на сайте минкомсвязи сформировали заявку на подключение к тестовой
среде ЕСИА. Заявку одобрили, прислали документ с инструкцией и 3 файла. В инструкии
как таковых шагов нет, только логины и пароли для входа на госуслуги тестовые и описание
того, что должно прийти в ответ. 

Файлы типа .rar - по инструкции это якобы контейнеры с ключами для ЭЦП.
например, архив EsiaTest.006.rar содержит такие файлы:


header.key 
masks.key
masks2.key
name.key
primary.key
primary2.key


Все параметры для авторизации в принципе понятны, кроме как раз подписи.
Вот как раз с формированием ЭЦП у меня проблемы.

В документе сказано формировать ее так:


  Подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений
четырех параметров HTTP–запроса: scope, timestamp, clientId, state (они у меня есть).
Подпись должна быть закодирована в формате base64 url safe. Используемый для проверки
подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной
записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА
поддерживает алгоритмы формирования электронной подписи RSA с длиной ключа 2048 и алгоритмом
криптографического хэширования SHA-256, а также алгоритм электронной подписи ГОСТ Р
34.10-2001 и алгоритм криптографического хэширования ГОСТ Р 34.11-94.


Помогите сформировать эту подпись! Как все это реализовать на c# ?
Заранее благодарю
    


Ответы

Ответ 1



Шаги по интеграции вы вряд ли где-то найдете. Есть только методические рекомендации и регламент работы с ЕСИА, но адекватного описания процедуры "как это сделать на C#" там нет :) То, что вам прислали вместе с ответом на заявку — это просто примеры разных тестовых аккаунтов для отладки работы, т.е. это НИКАК НЕ СВЯЗАНО с подписью ваших запросов к ЕСИА. Вот команды которыми мы генерирует правильный сертификат: openssl req -nodes -sha256 -newkey rsa:2048 -keyout secret.key -out request.csr -subj /C=RU/ST=Rostov-na-Donu/L=city/O=COMPANY\/emailAddress=EMAIL@site.ru/ openssl x509 -req -sha256 -days 3650 -in request.csr -signkey secret.key -out cert.crt -extfile /etc/ssl/openssl.cnf -extensions v3_ca openssl x509 -in cert.crt -text Соответственно в нужные места нужно подставить правильные данные о компании почту и т.п. это команда работает под линуксом при этом в файле /etc/ssl/openssl.cnf надо добавить(изменить) следующую секцию: [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = emailProtection, clientAuth subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer в результате вы получите работающий сертификат cert.crt и ключ secret.key Но это будет только начало. Там еще вагон и маленькая тележка нюансов по части обмена данными с ЕСИА. Вот тут есть готовое решение, в т.ч. и на C#: esia.pro Оно платное, но помимо готовой реализации там еще проконсультируют по процессу интеграции и оргвопросам.

Ответ 2



У нас подпись заработала как-то так: public static byte[] Sign(X509Certificate2 certificate, byte[] data) { if (data == null) throw new ArgumentNullException("data"); if (certificate == null) throw new ArgumentNullException("certificate"); // setup the data to sign ContentInfo content = new ContentInfo(data); SignedCms signedCms = new SignedCms(content, true); CmsSigner signer = new CmsSigner(certificate); var sha256 = new Oid("2.16.840.1.101.3.4.2.1", "sha256"); signer.DigestAlgorithm = sha256; // create the signature signedCms.ComputeSignature(signer); var signature = signedCms.Encode(); return signature; } С base64 там всё не очевидно: Convert.ToBase64String не подходит, не достаточно точно реализует стандарт. Использовал вот такой метод: public static string Base64UrlEncode(byte[] arg) { string s = Convert.ToBase64String(arg); // Regular base64 encoder s = s.Split('=')[0]; // Remove any trailing '='s s = s.Replace('+', '-'); // 62nd char of encoding s = s.Replace('/', '_'); // 63rd char of encoding return s; } Проверка их подписи - это очередной ребус. Можно предположить, что это процесс обратный процессу подписания, т.е. как-то так: public static bool ValidateCmsSignature(byte[] data, byte[] signature, X509Certificate2 certificate) { bool result = false; if (data == null) throw new ArgumentNullException("data"); if (signature == null) throw new ArgumentNullException("signature"); if (certificate == null) throw new ArgumentNullException("certificate"); // setup the data to sign ContentInfo content = new ContentInfo(data); SignedCms signedCms = new SignedCms(content, true); try { signedCms.Decode(signature); signedCms.CheckSignature(new X509Certificate2Collection(certificate), true); result = true; } catch (Exception ex) { var msg = ex.Message; } return result; } И этот метод работает для проверки нашей подписи, но не подходит для их подписи. А почему? Если мы сначала формируем текстовую строку, потом создаем отсоединенную подпись по ней, и потом всё это кодируем в base64, то они формируют два JSON'а: HEADER и PAYLOAD, потом кодируют их по отдельности в base64, и вот потом формируют подпись по строке HEADERbase64.PAYLOADbase64. А потом уже и подпись кодируют в base64. Итого, метод для проверки их подписи выглядит как-то так: public static bool ValidateSignature(byte[] data, byte[] signature, X509Certificate2 certificate) { bool result = false; using (var csp = (RSACryptoServiceProvider) certificate.PublicKey.Key) { using (var hasher = new SHA256Managed()) { var hash = hasher.ComputeHash(data); string id = CryptoConfig.MapNameToOID("SHA256"); bool isDataok = csp.VerifyData(data, id, signature); bool isHashOk = csp.VerifyHash(hash, id, signature); // можно ещё так //RSAPKCS1SignatureDeformatter rsaDeformatter = new RSAPKCS1SignatureDeformatter(csp); //rsaDeformatter.SetHashAlgorithm("SHA256"); //bool isHashOk2 = rsaDeformatter.VerifySignature(hash, signature); result = isDataok && isHashOk; } } return result; }

Ответ 3



А вообще уже есть в NuGet полезнейшая библиотечка, с которой всё становится легче: https://www.nuget.org/packages?q=esia.net В наши времена первопроходимцев так не баловали :))

среда, 18 декабря 2019 г.

Активация учётной записи за/против, варианты

#защита #авторизация #активация


Недавно задался вопросом по поводу авторизации.
При регистрации на сайте автоматически генерируется пароль и отправляется на почтовый
ящик.
Интересны за и против этого способа и другие варианты на подобие активации через
уникальный код.    


Ответы

Ответ 1



Активация учетной записи через письмо заставляет пользователя делать массу вещей, прежде чем он увидит Ваш драгоценный сайт. Как правило страдает первое впечатление от сайта.. Мое мнение: Никогда не генерируйте пароль автоматически и не посылайте его на почту. Дайте пользователю свободу выбора, и избавьте его от необходимости менять этот пароль сразу после регистрации. Отправьте пользователю на почту ссылку для активации, но предоставьте ему сразу доступ к сайту. + показывайте где-нибудь на видном месте, что аккаунт нужно активировать. Почистить раз в неделю/месяц неактивные и неактивированые аккаунты не так сложно Сделайте возможность входа посредством OpenID или при помощи популярных соц. сетей. Не каждый пользователь захочет регистрироваться, а вот сразу получить доступ - уже другое дело

Ответ 2



Отправкой на телефон кода активации.. Но тут думаю люди испугаются за средства на счету)

Ответ 3



Терпеть не могу активацию учетки через письмо на мыло!!! Бывает что сижу на работе и регистрируюсь на каком-нибудь ресурсе на свое мыло, а открыто в это время рабочее, и приходится перелогиниваться, подтверждать то что я не бот, и опять перелогиниваться, да я к тому времени рискую забыть на кой черт мне этот сайт нужен был... P.S. все изложенное IMHO UPD. Об усиленной защите. Регистрировался на стэке, не используя левые акки. 1.Ввел мало символов в пароле - назад. 2.Ввел не ту капчу (жесткая видать попалась) - назад. 3.Ввел ту капчу, ту длину пароля, но в пароле нужны разные символы/регистры - назад... Мне показалось это все немного лишним.

Ответ 4



Я за активацию учетной записи только на тех сайтах, где это действительно нужно. Т.е., на e-mail будут постоянно приходить какие-то важные уведомления.

Ответ 5



Активация аккаунта с помощью почтового ящика создана не для того, что бы раздражать пользователей. Первоначальное и самое главное ее предназначение - обеспечение правильности и корректности введенных регистрационных данных пользователя. Если пользователь ввел неверный адрес почтового ящика, то сразу же исчезают функции: ► Восстановления утерянного пароля при помощи почты. ► Рассылка новостей или информационных писем, в том числе диалоги с администрацией портала. ► Смена почтового ящика(как подтвердить смену?). ► Возможность просмотра профильной информации в регистрационном письме пользователем. Следовательно он не сможет вспомнить свой логин или даже адрес сайта в случае его потери. ► Защита от ботов. и многие другие... Рекомендую, для сохранения анонимности данных пользователя, на почту не высылать пароль, вдруг адресат будет неправильным.

Ответ 6



Зло. Вот Вам не пофиг, реальный у меня email или нет? С точки зрения рассылки спама - вариант самое оно, а как для людей - ну его..

четверг, 5 декабря 2019 г.

Как back-end узнаёт о Google-авторизации в Android-приложении?

#android #ios #ruby_on_rails #авторизация #google_api


Я разрабатываю серверную часть приложения на Rails.
Front-end — мобильное приложение на Android / iOS.

Задача — в приложении должна быть возможность входить через Google-аккаунт. Но я
не понимаю, как всё это должно взаимодействовать.
Даже если пользователь авторизуется именно в приложении, как back-end об этом узнает?
    


Ответы

Ответ 1



Делается это так: На клиенте каким-то образом (через SDK соц.сети или через браузер (в т.ч. встроенный в приложение)) юзер авторизуется в вашем приложении. Под последним имеется в виду набор из сгенерированных соц.сетью ключей, которые надо указывать при обращении к API оной. В случае гугла оно, вроде, и не нужно. После авторизации, в зависимости от соц.сети и всяких разных условий (секурность там всякая etc) с клиента на ваш сервер шлётся ID юзера (случай гугла), authCode или accessToken. В зависимости от того, что именно клиент вам присылает надо или валидировать ID, или обменять authCode на accessToken. Если присылается сразу accessToken то переходим к след. пункту. Теперь у вас есть все возможности получения всех возможных (разрешённых юзером) данных юзера. Либо как в случае с гуглом, после проверки присланного ID вы получаете объект юзера и делаете с ним что хотите (в БД кладёте, например или обновляете дату его последнего посещения) или, имея токен запращиваете его данные из API соц. сети. Вот гугловая дока по поводу сервера: https://developers.google.com/identity/sign-in/web/backend-auth Там написано, что есть либы под JAVA, NODE.JS, PHP, PYTHON

воскресенье, 1 декабря 2019 г.

Чем опасна авторизация на форумах через учетную запись социальных сетей?

#веб_программирование #авторизация #vkontakte_api #facebook_api


Доброго времени суток!
Я не собираюсь заниматься разработкой %сабж%. Мне интересен сам принцип, который
заложен в авторизации пользователя на различных форумах (в том числе сомнительного
происхождения) при помощи новых "модных" возможностей, используя красивые кнопки, на
подобие: "ВКонтакте", "Фэйсбук" и прочих соц.сетей.

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


PS: Будет полезно, если будут прямые ссылки на техническую документацию или описание
данной возможности авторизации к вашим ответам/комментариям.
Сильно умно не пишите, не силен я в web разработке и всяких там систем авторизаций...Мне
бы как-нибудь по-простому :-)

Очередной раз заранее вас благодарю за ваши ответы.    


Ответы

Ответ 1



По-простому: форум доверяет ВКонтакту (кто же не знает ВК!). Приходит на форум юзер, говорит, «Я Вася из ВК», форум сам напрямую бежит к ВК и уточняет, «ВК, это точно Вася?», ВК подтверждает, «да, это Вася из ВК». При этом про Васю ВК лишней инф-ии не раскрывает. Даже email не даёт - только имя-фамилию, id и ссылку на картинку с физиономией. Другие соц. сети, или, например, Google, светят email человека. В таком варианте злоупотреблений быть не может. Чтобы форум мог нагадить человеку, нужно дополнительно запросить каких-то прав, разрешений, установить приложение и т.п. ВК не дурак, и об этом подробно напишет: "Приложение такое-то запрашивает доступ к вашим ключам от квартиры и кошельку - дать?". От дурака особо не защитить, конечно, но если люди голову не выключали, то злоупотреблений не произойдёт.

Ответ 2



Ну обычно схемы работают достаточно просто - форум запрашивает у сервера соц сети форму авторизации (редирект с токеном), пользователь авторизуется у на сервере соц сети, соц сеть отдаёт новый токен форуму. По этому токену он может спросить у сервера соц сети авторизован ли пользователь, его имя ну и прочиее данные которые разрешены пользователем соц сети. общая схема примерно такая. Возможности использовать в корыстных целях нету, только если есть бреши у соц сети. На уровне апи такой возможности естественно не предусматривают.