получение Guid на Lotus Script

  • Автор темы Автор темы Реник
  • Дата начала Дата начала
У нас версия нотуса 7.0.1 у большинства людей. Так что не прокатит ((
 
Да тут у нас ситуация с заказчиком задания немного запутанная: они говорят , что лотусиный UNID их не устраивает, потому что "якобы " он задваивается.
назовите для заказчика лотусиный унид GUIDом и не мучайтесь :offtop: Или попросите заказчика аргументированно доказать что их не устраивает.
 
Ну вот про то и говорилось. в 8ке 1.5 джава, в 7 1.4.2.
Ну так я ж про то и говорил :offtop:. А что касается семёрки, то гугль даёт море ссылок на различные библиотеки генерации guid. Как использовать сторонний jar в лотусовой jvm Imike объяснял не один раз.

P.S.
Да тут у нас ситуация с заказчиком задания немного запутанная: они говорят , что лотусиный UNID их не устраивает, потому что "якобы " он задваивается. Врут наверное. Все мои попытки их убедить в обратном ни к чему не привели. : давай GUID и всё тут.
А Вы их сюда пошлите :)
 
Да тут у нас ситуация с заказчиком задания немного запутанная: они говорят , что лотусиный UNID их не устраивает, потому что "якобы " он задваивается. Врут наверное. Все мои попытки их убедить в обратном ни к чему не привели. : давай GUID и всё тут.
А что помешает задвоить этот пресловутый GUID?
Уникальность юнида( в пределах реплики ) гарантируется и контролируется domino. Т.о., в пределах одной базы вы можете быть абсолютно уверены, что разные unid адресуют разные объекты. А кто будет гарантировать уникальность самопальных GUID-ов? Даже если механизм их генерации абсолютно надежен, кто гарантирует, что значение не будет присвоено в обход механизма?
Используйте replicaid + unid, и не заморачивайтесь. А для удовлетворения заказчика добейте получившиеся 48 символов их же хэшем до 128 символов и будет всем щастье :-)
replicaID + UNID + @Password( replicaID + UNID ) + @Password( @Password( replicaID + UNID ) ) + ...
 
turumbay
replicaid тоже самопальными методами меняется :offtop:
 
turumbay
replicaid тоже самопальными методами меняется :offtop:
дык кто же спорит? :-)
даже без самопала - штатными средствами враг может создать еще одну реплику на сервере.
Я к тому клоню, что для задачи идентификации объекта хватит replica + unid. А поломать можно все. И чем больше шкаф, тем громче падает.
Если заказчик знает как обходить уникальность связки в пределах сервера - он должен понимать, что и любой другой вариант можно обойти.
GUID - это способ создавать уникальные объекты, а не способ запрещать создавать одинаковые :-)
 
то есть как я понял: самый прсоой способ решения проблемы- передавать им UNID документа +ReplicaID базы и пошли они на фиг со совим GUID. :(
 
то есть как я понял: самый прсоой способ решения проблемы- передавать им UNID документа +ReplicaID базы и пошли они на фиг со совим GUID. :(
"вам шашечки, или ехать?" вы хочите 128-битных ключей - их есть у меня.
Что делать-то планируется с ним? Оно "для чего-то конкретного надо" или "просто так надо"?
 
мне просто надо получить GUID документа и передать его в качестве параметра в отдельный метод. больше ничего от меня не требуется.
 
GUID - 16 байтный идентификатор. NotesUNID - тоже 16 байтный идентификатор. Дополнить всякими ReplicaID не получится.

Реник, спросите у этих людей, что они в дальнейшем намереваются делать с этим GUID-ом? Может он им нужен просто для понта :KillMe:
 
Guid я потом передаю в отдельный метод в качестве параметра
 
А что этот метод делает то? :KillMe: Зачем вообще этому методу какой-то левый идентификатор?
 
result = @Password(Notes certified public key* + replicaID + UNID)

где Notes certified public key* - поле в документе текущего сервера или чтобы уж точно добить - текущего пользователя :KillMe:

И потом ещё взять, к примеру, последние 16 символов из 32-х, которых вернула функция @Password (при исключении скобок).
 
ехатью GUID я передаю в качестве параметра в метод сторонний
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab