Так просто у ТС не получится. У него второй пользователь (с другим логином/паролем) портит то, что делал первый, потому как...

Ну, хорошо, доступ к диску - это плохо. Знаю, что решение некрасивое, мягко говоря.
У базы данных - свой сервер, понятно. Но все же это предотвратило бы хотя бы бОльшую часть попыток создания второго окна. Это уже что-то, нет?

Вы правы. Тогда другой вариант: создать в БД табличку с ip адресами залогиненных пользователей. Тогда с одного PC не смогут залогиниться несколько пользователей, что ТС, вроде, и нужно, когда он пишет о запрете второго окна.

>> Как я понимаю, когда юзер куда-то логинится, его логи/пароль проверяются по соотв. базе данных. Можно ввести дополнительное поле в таблице пользователей БД, которое отвечает за то, залогинен пользователь или нет.
Нет, немного иначе, поскольку речь идет о разных логинах (там такая схема, что валидировать изменения, произведенные в БД одним юзером, может только другой юзер, поэтому вот так это предписание и обходится левым образом, иначе много геморроя).
Т.е. есть реальные люди и есть аккаунты - это разные вещи. На одной Юникс-машине могут одновременно работать несколько человек. По той схеме, что Вы предлагаете, сможет работать только один.
Так что привязка должна быть не к к аккаунту, а все-таки к ID сессии, которое принадлежит одному человеку, именно это значение должно проверяться, если такое ID уже зарегистрировано, то второе окно не открываться.. Нет, впрочем, это тоже не годится. А что, если юзер закрыл окно и ушел? Завтра придет - сессия та же, окно не открывается?
Я думаю, решение надо искать в том, что насильственно перезапускать сессию, но как? Один жесткий тайм аут на Томкате ведь не поможет.

>> ААААААА! Сделайте мне это развидеть!
Товарищи, это П№;%:ЕЦ! Поймайте аффтора этого .... продукта вторичной переработки и дефабержируйте его. Не дай бог он размножаться будет.
Его уже и след простыл. Я понятия не имею, кто это был. Наверно, в Яве он рубит примерно так же, как и я, который на ней никогда раньше ничего не делал. Хотя, скорее, лучше :)
>> Хозяин - барин. Посмотрите в Task Manager-е, например, сколько явовских процессов у вас бегает. Но ели у вас не прав локального администратора вы все процессы можете и не увидеть.
У меня там явовские процессы, не только с этим связанные. Сам Эклипс тоже запускает явовский процесс.
>> Причины я вам раза три назвал. Ваша логика работать может только по случайному стечению обстоятельств (и, похоже, только в микроштофовском иксплодере). По-хорошему и третий апплет не должен был ничего увидеть и так же запуститься как и предыдущие два.
Да, но на третьем окне всегда строго срабатывает. Всегда!
И Ява-консоли всегда две. Не говорит ли это о том, что и ява-машины в браузере запускаются ровно две?
>> А откуда берется это значение? (540C407B5B9122D19AFC1588C2A49579) Кто его генерирует, или оно прошито в клиента?
А фиг его знает, сейчас, как Вы понимаете, не могу посмотреть. И код до понедельника не могу прислать.
Прошито - нет, не прошито, оно меняется.
>> Сурово. При запуске нового клиента он тоже не меняется?
В том-то и дело, что нет! Если машина (винда) и айпак те же, то при запуске нового клиента не меняется. А логин уже потом происходит. И после него, естественно, тоже не меняется.
>> Как ваш апплет общается с сервером? RMI? (у вас ведь точно апплет, да?)
Да, RMI, да, точно апплетка.

А откуда у пользователя второй логин?

Всегда это значит на одной и той же машине на одном и том же браузере одной и той же версии запускающем JRE одной и той же версии. То что эта проверка срабатывает сейчас, не факт что она сработает с другим браузером и с другой версией явы.
url поправлен
К сожалению, параноидальные настройки форума портят всё, где слово скрипт и апплет в английской транскрипции написаны.
http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html
Так должно сработать
Сейчас апплеты загруженные с того же самого codebase и с тем же самым архивом могут быть запущены в одном JRE. Никто не гарантирует что они будут запущены в одном.
Вроде как есть трюк - из неподписанного апплета писать и читать куки через яваскрипт используя JSObject. Опять же - трюк, даже если он у вас сработает сейчас не факт что он сработает после апдейта явы или браузера.

Говорит. Говорит ли это что-то о том что никогда не будет запущена третья или четвертая? Нет.

Подведем итоги. Процесс у вас такой.
1. Запускается веб-сервер.
2. На вебсервере поднимается ваш сервлет.
3. Ваш сервлет запускат с помощью класса StartServer RMI сервер на той же машине, на которой поднят веб-сервер.
4. Юзер Ю открывает в браузере страничку на которой находится ваш апплет.
5. В это момент у вас (под контролем непонятно кого) запускается (вернее этот кто-то по волшебству узнает что за клиент и откуда-то берет или делает новую сессию) ваша "сессия" (точно не томкатовская HttpSession?). Апплет к RMI серверу пока что не обращался.
6. Апплет А1 предлагает юзеру залогинится, юзер вводит логин/пароль Х.
7. А1 по RMI аутентифицирует логин юзера Ю как Х.
8. Ю открывает второе окно браузера, в котором открывает ту же страничку.
9. Каким-то колдунством кто-то выясняет что это юзер Ю с той же машины, и диалог с 2-м апплетом (А2) пойдет в той же самой сессии что и с А1.
10. А2 предлагает юзеру залогинится, юзер вводит логин/пароль У.
11. А2 по RMI аутентифицирует логин юзера Ю как У.
12. А1 и А2 параллельно работают с данными через RMI, оба логина и Х и У имеют права не только на чтение но и на модификацию данных, так как доступ к данным авторизируется сессией, а она у них одна.
13. А1 и А2 помирают, потому как Ю не логаутится а просто выключает браузер. Сессия остается (все там же, черт знает где).
Поправьте меня где я ошибся. Или если все неправильно - напишите как оно на самом деле происходит.

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

для описанной мной выше ситуации

-----
Мои советы были по ситуации именно в заявленном тобой контексте.
У тебя же от этого имеется пожалуй только статичная <HTML>-страничка.
Все остальное - <RMI> - с которым Я может быть и справлюсь, но давать
какие-либо советы - воздержусь - уже лет 15-ть его не видел.
П.С. Зарезав все кроме 80-го порта ты бы получил просто неработающий
<RMI> - у него дефаултный порт 1099. Это простейший тест на Веб-ность
системы и дальше бы искали что там не так.

Я думаю, что Вы описали все правильно. Уточню тока пару деталек.
>> точно не томкатовская HttpSession?
Скорее всего она.
>> 9. Каким-то колдунством кто-то выясняет что это юзер Ю с той же машины, и диалог с 2-м апплетом (А2) пойдет в той же самой сессии что и с А1.
Никакого колдовства нет, по-видимому, сессия привязана к IP.
>> 12. А1 и А2 параллельно работают с данными через RMI, оба логина и Х и У имеют права не только на чтение но и на модификацию данных, так как доступ к данным авторизируется сессией, а она у них одна.
Почти так. Я опустил для простоты, что там они еще выбирают некоего "манданта" (всего этих мандантов три, один называется "дефолт", другой основной, а третий - *. В базе данных прописаны только первые два. Изменять данные имеет право только основной мандант, остальные два имеют только права на чтение, вот тут и возникает проблема: если в одном окне выбран дефолт или *, то измененные данные записываются на счет дефолта и в итоге теряются). Но для того, чтобы решить проблему, все это несущественно.
>>13. А1 и А2 помирают, потому как Ю не логаутится а просто выключает браузер. Сессия остается (все там же, черт знает где).
На веб-сервере?
>> Вроде как есть трюк - из неподписанного апплета писать и читать куки через яваскрипт используя JS- -.
А что такое "неподписанный" апплет?
Разве на самой Яве читать куки и писать в них нельзя? (если вопрос глупый, не убивайте, никогда с этим дела не имел)
Ну, и главное: если окно закрывается, куки об этом узнают?

>> Вот при успешном логине и убивай текущую сессию и создавай новую. Будут, правда,
недовольные потерей данных в сессии юзвери, но это меньшая и решаемая проблема
по сравнению с разбором полетов тех же юзверей в одной сессии.
Ну, поскольку юзеры - это наше фахабтайлюнг, то я им ничего предписывать не могу.
И потом, как это убивать сессию после логина? Заставлять их логиниться два раза подряд?
Так они явно будут против.
>> На одной Юникс-машине могут одновременно работать несколько человек.
------
>> Только не говори, что все они будут сидеть в одной сессии - в этом случае решения
просто не будет
Нет, нет, каждый из них сидит в своей сессии.

>> А откуда у пользователя второй логин
У нас пользователи не простые, а блатные, как курочка Ряба...

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

если окно закрывается, куки об этом узнают?
------
Когда закрувается окно, то в бровсере, обычно доступно для <JS> событие закрытия окна.
Соответственно, можно прописать в куках, что событие закрытия имело место.
Аналогично и по открытию окна - есть событие открытия окна и возможность что-то сделать.
Пользоваться этим, однако, не стоит - не при всяком закрытии окна будет иметь место это
событие.
Но это - <Java S cript>. Как это делается из апплета - не знаю.

Тогда она скорее всего не связана с IP адресом. Насколько я помню томкат а.) такого не умеет б.) считать что все запросы приходящие с одного IP принадлежат одной сессии - большая дыра в безопасности.
Посмотрите, у вас куки JSESSIONID для вашего сервера (его домена) в IE появляется? Какое у нее значение? Тоже самое что выдает ваш лог в "DCC_4 (25) I: request for access key: 540C407B5B9122D19AFC1588C2A49579" Скорее всего у вас идентифиация по куки используется.

Если она остается на веб-сервере то она через полчаса помрет. Стандартная настройка томката - время жизни Http сессии 30 минут.

Что такое SSL сертификат знаете? Апплеты можно подписывать (sign). Подписанному (signed) апплету браузер может дать право выйти из "песочницы" - читать и писать файлы, открывать соединения с другими хостами, читать системные переменные, изменять куки и те пе.
Неподписанному апплету браузер доверять не имеет права. Почитайте, например, docs.oracle.com/javase/tutorial/deployment/applet/security.html

На этот вопрос я могу ответить четко и однозначно: "когда как" :)
Комбинировать надо. Куки без expiration удаляются браузером когда он закрывается. Но не отдельный таб. Чтобы при закрытии отдельного таба удалить определенные куки - яваскрптом ловим (как его правильно, этот ивент... ) unload вроде бы у окна и сами их трем.
У меня еще один вопрос возник - а как ваш апплет общается с RMI сервером? Вообще-то на другой порт (1099) соединение неподписанному (не привелигериванному) апплету открывать нельзя.
И давайте сформулируем что же вам надо. "запретить открытие второго окна" = не давать больше чем одному логину (X и Y в моем примере) работать в одной и той же сессии
Т.е. если в сессии S1 (с идентификатором вроде 540C407B5B9122D19AFC1588C2A49579) уже залогинен пользователь как X, то не давать еще одному пользователю логинится (как X или как Y - не важно) в этой же сессии?
А в другой сессии S2 (с другим идентификатором, с другого компьютера, например) можно?
Или что-то другое?

Тогда я не понял, что Вы имеете в виду.
Юзер залогинился, после этого убивается сессия. А как он работать будет, без сессии?

Непрграммистское начальство.

Они сидят на одной Юникс-машине, но компы-то у каждого свои и айпаки тоже свои.

Я сейчас проверил куки и не нашел никаких кук, связанных с Юникс-машиной, как ни странно.
Искал здесь: C:\WINDOWS\Profiles\cb3wech\Local Settings\Temporary Internet Files, но и в других местах тоже.

Но эта дыра уже есть де-факто.

Нет.

Но только при неактивности, как я понимаю.

Апплет подписанный, я просто не понял вчера Вашего вопроса.

Да, именно так, совершенно точно

Юзер залогинился, после этого убивается сессия. А как он работать будет, без сессии?
------
Когда второй юзер логинится - у тебя уже есть сессия первого (с того же хоста) залогиненного юзера - вот ее и надо прибить.
Они сидят на одной Юникс-машине, но компы-то у каждого свои и айпаки тоже свои.
------
Пожалей мою голову - у меня ведь тоже работа и ее делать надо..
Ну хоть немножко привел бы в порядок мысли.
Как Я читаю:
- есть Юникс
- у Юникса есть ИП
- на Юниксе работают несколько пользователей... ну ладно - несколько <BASH>ей запущено...
Дальше:
- у каждого свой комп - это внутри Юникса? Используется какая-то ВМ?
- и ИП свои - получается что-то непотребное - взяли никсовый ИП и порезали на части для юзверей...
Бред? Угу...
Когда ты обьяснишь, что на Юниксе крутится <RMI>-сервер, то возникнет несколько вопросов
- все клиенты обслуживаются одним работающим сервисом или для каждого поднимается свой
сервер. Бо, если сервер один, то там как-то диспетчируются запросы и в том месте надо смотреть
как быть с пользователем. Ну а если под каждого свой сервер - то надо искать наличие дыры и
возможности просмотреть всех залогиненных юзверей...

Я должен сделать еще важное уточнение.
Соединение по RMI делается только в Эклипсе, для тестирования.
На браузере для этого используется сервлет.
Сейчас я и Эклипс переключил на сервлет, пытаюсь соединиься со скачанным на винду Томкатом.
Тайм аут установлен на 7200 минут, это ровно 10 дней, сессия - на Томкате, с http, и абсолютно точно привязана к IP, это я проверил.

Да, до этого я уже допер
Только старая сессия не должна убиваться, надо просто запускать новую для нового юзера и не портить настроение соседу (ну, т.е. самому себе, если не понятно).
Вот как именно запускать ее, я еще не разобрался, не подскажешь?

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

См. выше. RMI у каждого свой и только для тестирования на Эклипсе. В боевых условиях вместо RMI используется сервлет.