Есть БД (MySQL) на хостинге (со стандартным php)
Нужен клиент для работы с БД с условиями:
1) в некоторых случаях БД может ставится локально на машину (однопользовательская, нет инета)
2) требования к интерфейсу довольно высокие (как к нормальному desktop-у)

Хотелось бы уточнить насчет swing-клиента (понятно что можно реализовать php скрипты и view = javascript framework (ExtJS например), затем локально также поставить PHP и apache и условия и 1) и 2) будут выполнены)

Но поскольку java ближе хотелось бы заюзать ее...
Так вот вопрос: КАК корректно реализовать доступ к удаленной БД из swing-клиента, заюзывая web start и JDBC конечно.

Если параметры доступа к БД будут храниться на клиенте, даже будучи зашитыми в java-код и передаваясь по https -они ведь могут быть определены из кода, а значит реальна ситуация когда будет получен несанкционированный доступ к БД ?

Help please...

Хрюхрюшкин. Help please...
бла-бла-бла...

Если параметры доступа к БД будут храниться на клиенте, даже будучи зашитыми в java-код и передаваясь по https -они ведь могут быть определены из кода, а значит реальна ситуация когда будет получен несанкционированный доступ к БД ?
Для ограничения несанкционированного доступа придумали такую вещь как логин и пароль.

"такая вещь как логин и пароль" - это и есть "праметры доступа к БД" ?
Если они будут прошиты в java-коде, то значит их можно будет получить его декомпиляцией,
или имеется ввиду что каждый пользователь клиентской части - должен быть user-ом БД?

Хрюхрюшкин.
Каждый человек, работающий с твоей системой, вводит свой логин и пароль.
Те, кому не положено много знать, по своему логину и паролю получают мало. А кому положено — много.
Логин — может быть логином DB. А может и не быть. В таком случае юзер вбивает свой логин и пароль, но автоматически коннектится к жестко заданными Л/П, например connect\connect.

Так вот и я об этом, где храниться этот connect\connect (при условии что уровня сервера приложений нет, т.е. есть только удаленная БД и клиент) ? Если "connect\connect" прошит на клиенте - то его теоритически узнать можно, и если это общий user/pwd для работы с данными в БД, то узнав IP и порт можно подредактировать данные по своему желанию (с помощью всевозможных средств администрирования).


Хрюхрюшкин.
Когда он так логинится — у него должны быть права ровно на одну вещь — выполнение какой-то твоей внутренний функции, которая получил на вход введенные пользователем Л/П и скажет, разрешать доступ или нет...

А если БД - MySQL 4-я, без stored procedure... если бизнес логика прошита на клиенте (без сервера приложений скажем) - Или все-равно необходимо писать PHP-скрипты с логикой на сервере приложений, которые и будут реализовывать "выполнение какой-то внутренний функции"? Ведь если бизнес-слой необходимо выносить с клиента при работе с удаленной БД на уровень сервера приложений, тогда незачем и клиента тяжелым делать?

Хрюхрюшкин.Если всё так плохо, делайте каждого пользователя системы пользователем БД, если используете тяжелого клиента. Зашивать критичные данные (вроде настоящих логина и пароля) внутри приложения нельзя ни при каких условиях.

Спасибо за ответ, осталось узнать есть ли в 4-ой версии такие вещи (их аналоги) как "права вызывающего" и/или синонимы хотя бы :)

...мне в голову уже всякие "извраты" лезут:
единственный PHP скрипт, который принимает логин и пароль (системные, а не БД), которые вводит пользователь в swing-клиенте, PHP скрипт сам обращается к БД (напр.: к таблице user), проверяет права и если все ОК, возвращает логин и пароль к самой БД (ес-но, все передается по https...), далее (в сеансе :) ) swing-клиент работает через логин и пароль юзера БД, есть ли в таком варианте подводные баги?