Очень не хватает бандлов для phpdoc и, к сожалению, времени попробовать сделать самому. Было бы очень полезно. То что есть сейчас только рисует пустой комментарий без автокомплита по @. Хочется такой автокомплит, который будет работать внутри комментария в коде (@author, @param и т.д.) и иметь полный список тегов.
Вторая идея — выводить статус репозитория в проводнике. Т.е. делать svn status и раскрашивать имена папок в нужный цвет (иконки не нужны, только минималистичность, только хардкор).
> А разве гугл/яндекс не пошлют меня лесом, если я отправлю к ним пользователя, не зная его идентификатор?
Конкретно гугл и яндекс не пошлют. ЖЖ, блоггер и ряд других — пошлют. Попробуйте сами взять любую библиотеку openid для любого языка и скормить ей эти discovery url: www.google.com/accounts/o8/id openid.yandex.ru/
Давайте порассуждаем немного логически. Если сайт предоставляет уникальный функционал по работе с соц. сетями (работа с изображениями/фото/френдлента), то да, доступ к api, бесспорно, играет важную роль. Но в 90% случаев рядовых сайтов нужна просто авторизация.
Теперь давайте про идентификатор. Разрешать какие-угодно внешние oauth/openid провайдеры, конечно, глупо. И в реальной жизни нашей целью скорее станет конкретный набор социальных сервисов. В случае с гуглом/яндеком для OpenId идентификаторы не нужны и, как я писал выше, для пользователя внешне все выглядит точно также.
Вк, фейсбук, твиттер, маил.ру, фликр — разрешают хеш в коллбеке. Для всего остального есть мастеркард OpenId. С одноклассниками не вязался еще, попробую :)
Я делал так: пользователь входит первый раз. Запрашиваю у oauth/openid email (это самый важный индентификатор). Генерирую пользователю ник (в любом случае). Далее все верно. Если провайдер oauth не отдает мыло — спрашиваю его у пользователя и не пускаю дальше. Пароль в данном случае вообще не нужен.
Почему-то автор не упоминает о таком важном моменте как уникальный коллбек, для того чтобы можно было идентифицировать пользователя, возвращаемого oauth сервером. Чтобы коллбек был уникален, достаточно добавлять к redirect_uri какой-либо параметр и присваивать в качестве значение генерируемый хеш. А также записывать этот хеш в сессию и сравнивать после возврата пользователя на сайт.
Иначе возможно атака в которой злоумышленник нажимает на ссылку авторизации, получает код, но не переходит на сайт для обмена кода на токен. Ссылка с кодом отдается жертве, и перейдя по ней, жертва привязывается к учетке злоумышленника. В результате злоумышленник может войти на сайт под видом жертвы.
А OpenID в данной статье незаслуженно унижен. Не вижу никаких сложностей с тем чтобы явно указывать сервер авторизации openid в ссылке на сайте (войти через гугл, войти через жж). Что в данном случае меняется? Для пользователя абсолютно ничего. Он так же нажимает на ссылку, переходит на сайт гугла и разрешает авторизацию. Зато в качестве большого бонуса, не надо писать кучу кода. Там где только oauth — пишутся небольшие классы для общего интерфейса авторизации. Там где openid — меняется только адрес ссылки логина (site.com/login/?realm={google|yandex|etc...}) и используется единый класс с разными значениями auth_realm.
Рекомендую почитать на эту тему книжки цикла Best Practise (хотя бы про тот же AD). Там все описано. И про теневые группы и про планирование групп/политик/подразделений…
Есть различные техники, которые помогают выйти из ОСа даже если вы не можете им управлять. Они просты до безобразия. Пару пробовал на себе — просыпался моментально.
Трактором пользуюсь более года, и за это время хорошо прочувствовал основной минус сведения на ПК — задержки. Боюсь в такой связке задержки вырастут еще больше =\
Вторая идея — выводить статус репозитория в проводнике. Т.е. делать svn status и раскрашивать имена папок в нужный цвет (иконки не нужны, только минималистичность, только хардкор).
Еще были какие-то идеи, если вспомню напишу.
Конкретно гугл и яндекс не пошлют. ЖЖ, блоггер и ряд других — пошлют. Попробуйте сами взять любую библиотеку openid для любого языка и скормить ей эти discovery url: www.google.com/accounts/o8/id
openid.yandex.ru/
Теперь давайте про идентификатор. Разрешать какие-угодно внешние oauth/openid провайдеры, конечно, глупо. И в реальной жизни нашей целью скорее станет конкретный набор социальных сервисов. В случае с гуглом/яндеком для OpenId идентификаторы не нужны и, как я писал выше, для пользователя внешне все выглядит точно также.
мастеркардOpenId. С одноклассниками не вязался еще, попробую :)Иначе возможно атака в которой злоумышленник нажимает на ссылку авторизации, получает код, но не переходит на сайт для обмена кода на токен. Ссылка с кодом отдается жертве, и перейдя по ней, жертва привязывается к учетке злоумышленника. В результате злоумышленник может войти на сайт под видом жертвы.
А OpenID в данной статье незаслуженно унижен. Не вижу никаких сложностей с тем чтобы явно указывать сервер авторизации openid в ссылке на сайте (войти через гугл, войти через жж). Что в данном случае меняется? Для пользователя абсолютно ничего. Он так же нажимает на ссылку, переходит на сайт гугла и разрешает авторизацию. Зато в качестве большого бонуса, не надо писать кучу кода. Там где только oauth — пишутся небольшие классы для общего интерфейса авторизации. Там где openid — меняется только адрес ссылки логина (site.com/login/?realm={google|yandex|etc...}) и используется единый класс с разными значениями auth_realm.