Как же надоели эти рекомендации. Стоит послушать несколько песен и поставить несколько оценок, как сервис начинает тебя одолевать своими «рекомендациями».
Как по мне — обычный внешний вид. Плюс минус вид с боку.
Если он функционален и прост в обслуживании, ест любую бумагу, не требует ставить каких-либо драйверов (которых обычно нет под Linux, а тем более под Linux ARM), протокол общения открыт и есть хоть какая-то тех. поддержка разработчикам — то очень круто.
— Иногда нужно помнить не только пароли, но и факт его наличия;
— А еще некоторые ресурсы, непонятно зачем, требуют периодической смены пароля;
— Бывает, что нужно запоминать чужие пароли. Например, доступ к FTP заказчика;
— Допустим сам захотел сменить пароль на каком-то ресурсе;
Как поступите?
Что там может не получиться? Одно дело доказывать надежность шифров, другое — использовать существующие (тот же AES). Это примерно как собрать самолетик из конструктора.
Реально можно генерировать пароли на любой вкус. Где-то сложные, где-то простые. Где-то только цифры.
Храню ответы на вопросы и прочую информацию. Потому что однажды, забыв ответ пришлось топать в офис Аэрофлота. А забыл, потому что никогда честно не отвечал.
Храню чужие пароли, пришедшие по работе или подработке. Тут вы вообще не можете их выбирать.
Пользуюсь на компьютере и телефоне (синхронизация по вебдав).
Хотел хранить фото документов, но решил не раздувать базу.
Активно пользуюсь функцией автонабора вместо буфера обмена. Это особенно удобно, когда надо набрать пароль по рдп или тимвьюверу. С общим буфером обмена вечно что-то не так.
Всего накопилось порядка 250 паролей. И это все очень удобно и безопасно. По крайней мере тем кому я могу быть интересен едва ли по силам получить доступ. Помимо шифрования файла я за свой компьютер никого не пускаю, всегда блокирую. Телефон закрыт пинкодом со стиранием памяти после 10 попыток (и никакой биометрии).
Но если всё-таки доступ к файлу кто-то получит — это будет катастрофа.
Но не думаю что хранить в блокноте и считать хеши надёжнее, тем более в браузере и через инет.
Я думаю не за 2-3 часа, но на 2-3 выходного можно сделать собственное хранилище паролей и хранить их там (на Дельфи, например, или фрипаскале, их же даже в школе дают)
Неужели нельзя просто взять и сделать руками (велосипед, если хотите)?
Я не первый день занимаюсь разработкой веб-приложений и до сих пор не осилил спринг. Сейчас объясню что имею виду.
Когда я прочел книгу про Java EE и про Spring, я прям загорелся: «а что так можно было?». После того как начал искать в сети и пробовать — я почти во всем разочаровался.
1. Тот же DI — крутая штука, но я так и не понял когда ее крутость может пригодиться в бою. Мне всегда было достаточно Singleton-ов и ThreadLocal-переменных. Аналоги Session-бинов, по-моему уже не нужны, больше проблем будет, чем пользы; это можно сказать в целом про сессии на сервере.
2. @RequestMapping("/helloWorld"). По сути мы выставляем метод наружу. И этот маппинг — дополнительная, на мой взгляд, не нужная абстракция. В своих приложениях я выставил методы наружу по их собственному имени, например, /ru/example/Booking.list?param1=… Это понятнее.
Превратить get-параметры в параметры вызова, а результат функции в json не составило труда. Это действительно очень просто сделать.
3. Security. Все очень здорово придумано: определяешь роли и ассоциируешь их с пользователями. А методы с ролями. Но в бою это работает плохо и неэффективно, потому что в большой организации обязанности перекладываются из роли в роли постоянно. То одним нужен отчет, то другим. Кому-то можно заселять задним числом, кому-то нет (я про отель). Таких примеров каждый день прибавляется — грани между ролями плавающие. К тому же часто права должны быть параметрическими (например, хочется задать за какое количество дней назад человек может сделать отчет или, допустим, инспектор в отеле имеет доступ в раздел номера, но вносить правки должен мочь только для своего корпуса).
Каждый раз пересобирать и перевыкладывать проект из-за этого не хочется.
В своем проекте я иначе это реализовал.
Есть security-классы, которые описывают те или иные права. Для каждой роли (которые хранятся в базе) задается список классов и их значения (в виде json-а, например)
У методов задается аннотация со списком классов, которые должны быть у пользователя. Если у роли пользователя нет какого-то класса, то метод вообще не выполняется. Внутри модуля, при необходимости, я получаю экземпляры этих секурити-классов и кодом осуществляю нужные проверки.
Это более гибко и типобезопасно.
4. BeanValidation — вот это мне кажется мега-крутой задумкой. Особенно то, что аннотации можно передать на клиент и тот тоже будет выполнять проверки параметров. К сожалению, без контейнера это очень тяжело реализовать, потому, что тут без магии не обойтись: либо использовать нестандартные методы в AnnotationProcessing, либо модифицировать байт-код во время загрузки классов, либо велосипедить контейнер. Пути сложные, поэтому, пока не реализую, у себя я добавляю вызов проверяльщика первой строкой в каждый метод. Внедрять в проект контейнер только из-за BeanValidation не хочется.
Удивительно, но все это реализовано классами, которые можно пересчитать пальцами рук (ну, возможно и ног). Это действительно очень просто и новый программист быстро поймет как и что работает. И никакой магии. Проект деполится в Tomcat-е меньше чем за секунду. И при этом я не перетрудился, я же программист.
Ну и не стоит забывать про KISS:
На мой взгляд у почти всех back-end приложений две основных задачи:
1. положить в базу то что прислал пользователь,
2. взять что-то из базы и отправить пользователю.
Не усложняйте.
Интересно про Linux JAVA. Это какая-то java обертка под ваши нативные библиотеки? Или это чистая java?
Если он функционален и прост в обслуживании, ест любую бумагу, не требует ставить каких-либо драйверов (которых обычно нет под Linux, а тем более под Linux ARM), протокол общения открыт и есть хоть какая-то тех. поддержка разработчикам — то очень круто.
А как отличить хороший код от плохого? Есть какой-то исчерпывающий материал про это? Интересно для себя.
По-моему это хоть и полезно, но ерунда по сравнению с имплементацией правил футбола и AI. Ждём.
— А еще некоторые ресурсы, непонятно зачем, требуют периодической смены пароля;
— Бывает, что нужно запоминать чужие пароли. Например, доступ к FTP заказчика;
— Допустим сам захотел сменить пароль на каком-то ресурсе;
Как поступите?
Уже несколько лет пользуюсь компасом и доволен:
Всего накопилось порядка 250 паролей. И это все очень удобно и безопасно. По крайней мере тем кому я могу быть интересен едва ли по силам получить доступ. Помимо шифрования файла я за свой компьютер никого не пускаю, всегда блокирую. Телефон закрыт пинкодом со стиранием памяти после 10 попыток (и никакой биометрии).
Но если всё-таки доступ к файлу кто-то получит — это будет катастрофа.
Но не думаю что хранить в блокноте и считать хеши надёжнее, тем более в браузере и через инет.
Я думаю не за 2-3 часа, но на 2-3 выходного можно сделать собственное хранилище паролей и хранить их там (на Дельфи, например, или фрипаскале, их же даже в школе дают)
Я не первый день занимаюсь разработкой веб-приложений и до сих пор не осилил спринг. Сейчас объясню что имею виду.
Когда я прочел книгу про Java EE и про Spring, я прям загорелся: «а что так можно было?». После того как начал искать в сети и пробовать — я почти во всем разочаровался.
1. Тот же DI — крутая штука, но я так и не понял когда ее крутость может пригодиться в бою. Мне всегда было достаточно Singleton-ов и ThreadLocal-переменных. Аналоги Session-бинов, по-моему уже не нужны, больше проблем будет, чем пользы; это можно сказать в целом про сессии на сервере.
2. @RequestMapping("/helloWorld"). По сути мы выставляем метод наружу. И этот маппинг — дополнительная, на мой взгляд, не нужная абстракция. В своих приложениях я выставил методы наружу по их собственному имени, например, /ru/example/Booking.list?param1=… Это понятнее.
Превратить get-параметры в параметры вызова, а результат функции в json не составило труда. Это действительно очень просто сделать.
3. Security. Все очень здорово придумано: определяешь роли и ассоциируешь их с пользователями. А методы с ролями. Но в бою это работает плохо и неэффективно, потому что в большой организации обязанности перекладываются из роли в роли постоянно. То одним нужен отчет, то другим. Кому-то можно заселять задним числом, кому-то нет (я про отель). Таких примеров каждый день прибавляется — грани между ролями плавающие. К тому же часто права должны быть параметрическими (например, хочется задать за какое количество дней назад человек может сделать отчет или, допустим, инспектор в отеле имеет доступ в раздел номера, но вносить правки должен мочь только для своего корпуса).
Каждый раз пересобирать и перевыкладывать проект из-за этого не хочется.
В своем проекте я иначе это реализовал.
Есть security-классы, которые описывают те или иные права. Для каждой роли (которые хранятся в базе) задается список классов и их значения (в виде json-а, например)
У методов задается аннотация со списком классов, которые должны быть у пользователя. Если у роли пользователя нет какого-то класса, то метод вообще не выполняется. Внутри модуля, при необходимости, я получаю экземпляры этих секурити-классов и кодом осуществляю нужные проверки.
Это более гибко и типобезопасно.
4. BeanValidation — вот это мне кажется мега-крутой задумкой. Особенно то, что аннотации можно передать на клиент и тот тоже будет выполнять проверки параметров. К сожалению, без контейнера это очень тяжело реализовать, потому, что тут без магии не обойтись: либо использовать нестандартные методы в AnnotationProcessing, либо модифицировать байт-код во время загрузки классов, либо велосипедить контейнер. Пути сложные, поэтому, пока не реализую, у себя я добавляю вызов проверяльщика первой строкой в каждый метод. Внедрять в проект контейнер только из-за BeanValidation не хочется.
Удивительно, но все это реализовано классами, которые можно пересчитать пальцами рук (ну, возможно и ног). Это действительно очень просто и новый программист быстро поймет как и что работает. И никакой магии. Проект деполится в Tomcat-е меньше чем за секунду. И при этом я не перетрудился, я же программист.
Ну и не стоит забывать про KISS:
На мой взгляд у почти всех back-end приложений две основных задачи:
1. положить в базу то что прислал пользователь,
2. взять что-то из базы и отправить пользователю.
Не усложняйте.
Скорости впечатляют, но чудес же не бывает.
Спасибо.
Один символ увеличит вариантов в 72 раза по свойству степени.