Должны ли мои пользователи подключаться напрямую к базе данных? Как подключить пользователей к базе данных;
Во-первых, я должен упомянуть, что я новичок в базах данных;
В настоящее время я настраиваю сервер MySQL и не знаю, как подключить моих пользователей к базе данных; Я хочу, чтобы они могли использовать мое программное приложение для отправки определенных предопределенных запросов (SELECT / ALTER).
В настоящее время я делаю это так: я запрашиваю имя пользователя / пароль в своей первой форме. Затем я подключаюсь к базе данных, используя имя пользователя по умолчанию: «javaApp» / пароль: «javaApp», а затем проверяю, указаны ли данные в форма входа соответствует пользователю в UserTable;
Может ли кто-нибудь подсказать, как сделать это более эффективно / профессионально / безопаснее?
Может, какие-нибудь веб-сервисы или что-то в этом роде? У меня действительно нет никаких идей.
Как это решают профессиональные разработчики программного обеспечения?
Заранее спасибо!
Звучит нормально. Если вы хотите проверить учетные данные, введенные пользователем, вы должны сравнить их с данными, хранящимися в БД. Некоторые подсказки: 1) Не отключайте соединение и используйте его повторно. Не открывайте новое соединение для каждого пользователя. 2) Храните пароли в соленом и хешированном виде, а не в виде обычного текста.
Да, я использую заранее подготовленные операторы и подсолил свои пароли! Спасибо за вопрос!
Проблема в том, что, возможно, у меня одновременно подключаются несколько пользователей. Будет ли это проблемой, если все они будут входить в систему с одним и тем же пользователем javaApp?
Мой клиент не видит мой исходный код. Они могут использовать только приложение.
Если вы намерены применить единый набор разрешений ко всем пользователям, выдающим себя за javaApp, мне кажется, что это жизнеспособное решение для вас. Если каждому пользователю нужны уникальные роли / разрешения, то выдача себя за одного пользователя не поможет.
Если вы создадите пользователя SQL для каждого пользователя, подключающегося к вашей базе данных, им быстро станет чрезвычайно сложно управлять. Индивидуальные логины могут дать вам больше контроля над тем, к чему этот пользователь может получить доступ, но вы также должны убедиться, что у них нет большего доступа, чем им нужно, и они теряют его, когда должны. Будьте осторожны при предоставлении пользователям прав на управление схемой базы данных или даже данными DELETE, если у вас нет особой причины. Лучше всего предоставить вашему приложению доступ к базе данных для пользователя и дать пользователю только то, что приложение использует разрешения. Но ваши требования могут отличаться.
У меня есть несколько типов пользователей; Я добавлю еще две, чтобы иметь возможность содержать все разные роли пользователей, которые у меня есть.
@ luk2302, декомпиляцию не знал. Как я могу избежать такого события?
Вы не можете избежать декомпиляции, если у кого-то есть исходный jar-файл. Поэтому к этому нужно готовиться! У @DavidBrossard есть хороший пример того, как это сделать.
Мм понятно. Это кажется подходящим. И все же в этом сценарии, как я могу избежать отображения моего пользователя по умолчанию? Я не хочу, чтобы кто-то посторонний мог подключиться к моей базе данных и делать Бог знает что. Но я не знаю, как еще я могу управлять своим подключением к базе данных.
Ответы 1
Я бы не стал открывать базу данных напрямую. Я бы использовал слой между пользователем и базой данных, чтобы вы могли контролировать, как они могут запрашивать базу данных и что они могут получить.
Не определяйте соединение с базой данных в коде. Вместо этого используйте ресурс JNDI (особенно если вы работаете поверх сервера приложений, например Tomcat, который управляет ресурсами JNDI за вас). Это отделит ваш код от информации о подключении. Кроме того, вы можете использовать такие вещи, как пул соединений с JNDI, который повысит производительность вашего приложения (а также будет обрабатывать такие вещи, как закрытие соединения). Параллелизм будет обрабатываться пулом соединений. См. Это Статья Oracle о ресурсах JNDI и это специфично для Tomcat.
Используйте учетную запись службы, то есть учетную запись, которая будет использоваться для аутентификации приложения в базе данных. Эта учетная запись не имеет ничего общего с учетными записями пользователей, получающих доступ к вашему приложению. Ограничьте возможности учетной записи службы. Если все, что вы хотите сделать, это прочитать данные через приложение, ограничьте учетную запись службы только этим (по крайней мере, вначале).
Вы можете использовать ORM, например. Hibernate в Java, который даст вам абстрактное представление о базе данных. Это может быть слишком много для вас, если все, что у вас есть, - это одна таблица. В этом случае используйте то, что называется PreparedStatement.
Вы хотите, чтобы пользователи могли определять свои собственные операторы SQL. Это открывает перед вами множество атак SQL (ищите SQL-инъекции).
Никогда не храните учетные данные пользователя в открытом виде в базе данных. Хешируйте значения.
Наконец, взгляните на эти отличные лучшие практики.
Большое спасибо за ответ и предоставленные ресурсы! Кажется, это то, что мне нужно. Мне сейчас немного сложно понять, но, надеюсь, я смогу справиться. Если я могу спросить, есть ли другие подходы, подходящие для новичков, которым я мог бы следовать?
Хорошо знаю, что я использовал только стандартный код Java и коннектор JDBC. Ничего особенного. Я хотел, чтобы это было как можно проще; Но, похоже, этого недостаточно. Еще раз большое спасибо за интерес к моему вопросу!
Достаточно, если вы помните о вышеизложенном. Вы используете сервер приложений, например Кот?
Вы можете изучить структуру MVC - проверьте это: dailyrazor.com/blog/best-java-web-frameworks
Ха, совсем нет. Хотелось сделать его как можно более простым, поскольку ранний сервер базы данных тестировался на Raspberry PI. Я настроил только mysql-сервер.
MySQL также работает на Raspberry Pi? В таком случае проверьте h2
У вас есть серверная часть java или вы создаете приложение, которое упаковывается в банку и отправляется клиенту? Поскольку вы новичок: вы используете подготовленные операторы или что-то подобное для предотвращения SQL-инъекции? Правильно ли вы хэшируете и солите пароли?