Внимание! Вы просматриваете форум в ограниченном режиме – авторизуйтесь (вверху страницы) или зарегистрируйтесь, чтобы получить доступ ко всем возможностям форума (создание темы / ответа, доступ к спискам «Избранные», «Мои темы», «Непрочитанное»).
Компьютерные программы, авторские права и лицензирование
Grāmatvedības programma uzņēmumam kas sniedz pakalpojumus. К списку тем
Ilkak 12.08.2008 09:16
5 сообщений на сайте
5 сообщений на сайте
Ответы (133)
Вот и мне интересно. Потом "компитентное" лицо не привяжется, если у меня будут такие счета без собственноручной подписи? Получается, что предприятие само устанавливает этот порядок авторизации и этого вполне достаточно?
Кто придумал?
Да видимо кто-то из ваших, из больших. А потом уже все остальные подтянулись. Чужой пример же заразителен, как известно.
Хотя Латтелеком исправляется. Сначала предлагал на сайте заявочку на электронный счет оформить. Сейчас уже папирку прислал подписать, что мы согласны на электронный счет.
Да видимо кто-то из ваших, из больших. А потом уже все остальные подтянулись. Чужой пример же заразителен, как известно.
Хотя Латтелеком исправляется. Сначала предлагал на сайте заявочку на электронный счет оформить. Сейчас уже папирку прислал подписать, что мы согласны на электронный счет.
Альбин, так закон о бухии такой порядок предусматривает, порядок пользования программой на предприятии и устанавливается, у кого и какие права пользования.
Ага, вот чую, что Латтелеком это и придумал, у них был такой генератор идей, с которым мы сейчас с трудом справляемсяLOL
"Полгода воевали, что бы внизу заменили идиотскую строку - Счёт подготовлен электронно и годен без подписи, на " и авторизирован"" - я тоже заменила, пример в моём хранилище rekins_ar_autorizacijas_kodu.pdf
Domāju, ka autorizācija nozīmē vien to, ka rēķins sagatvots licencētā programmā, , kur katram lietotājam ir sava parole. Rēķinam programma ir piešķīrusi reģistrācijas numuru. Tā ka autorizācijas kods varētu arī nebūt.
Я вот ещё задумалась, а не добавить ли к коду авторизации фамилию, имя исполнителя рядышком. Было б, наверное, красивше :).
Если код авторизации завязан на пароле, который у пользователя может меняться, то кроме красоты - это ещё и удобно, сразу видно, кто ваял документ. Потому как искать его по коду авторизации в базе будет гораздо дольше
Ну если хорошо подумать, то пользователь может менять пароль хоть каждый день (и каждый час ). И "подводных камней", зависящих от технологии, там немало.
А я подумала и пришла к выводу, что нельзя строить код авторизации только на пароле. Даааааааа, :). У двух пользователей может случиться одинаковый пароль (нечаянно ). И никакой тады авторизации. Скорей всего лучше зашифровать логин, иль логин+пароль.
"Я наоборот поставила генератор случайных паролей." - а что пользователь сам пароль поменять не может? Генератор случайных паролейт обычно используют при первичном присвоении, а дальше пользователь сам меняет когда хочет и как хочет.
"Я наоборот поставила генератор случайных паролей." - а что пользователь сам пароль поменять не может? Генератор случайных паролейт обычно используют при первичном присвоении, а дальше пользователь сам меняет когда хочет и как хочет.
Закрыть
Краткое описание нарушения
Закрыть