Перехватывать и обрабатывать, если можешь.
Пробрасывать дальше, если обработать сам не можешь, а там есть, кому перехватить.
Не использовать вовсе, если в них нет необходимости.
В остальном - вы же не спрашиваете, как правильно работать с отверткой?
Инструмент есть инструмент, как вам надо - так и работайте.
По стороннему API вы рано или поздно получите данные с неуникальным id.
Если вся ваша обработка сводится к получению строки по этому id - можно просто сделать его уникальным ключом. Если вы будете связывать эту таблицу с другими или обрабатывать, обращаясь к набору строк - локальный id будет и эффективнее, и надежнее.
Alexander S, ну конечно!
Майкрософт купила авторские права на Скайп и по частям раздает их пользователям.
Полицейский эксперт после полицейской контрольной закупки будет выгораживать задержанного.
Клиенты, попершиеся в сервис переустановить винду, обычно приносят с собой список ключей на весь софт, который им нужен.
А лисички взяли спички...
Alexander S, исполнитель, оказывающий услуги по установке ПО, заведомо обладает знаниями, позволяющими ему определить лицензионную чистоту устанавливаемого ПО. Трудновато будет, знаете ли, запускать активатор и сохранять невинный вид.
Нет тут лазейки. Если к вам придет анонимный покупатель в штатском - можете подтереться своим "правильным договором".
"Другой пример" только демонстрирует, что вы не разбираетесь в законах. Потому что авторское право к лицензионным соглашениям не имеет ровно никакого отношения.
Зря дублируете. Пункт 3 - это предварительный сговор, к которому "правильный договор" будет первейшей уликой, а остальное - не то, чего хотят клиенты, и за это они платить не будут.
Без опыта написания собственного говнокода и неоднократного попадания на грабли - практически бесполезный список, имхо. Очень странное представление о коде может сформироваться у человека, который не пишет его сам. Не говоря о времени и силах, которые ему придется потратить на понимание того, чего он просто-напросто не пробовал сделать сам.
Обычно у новичков даже при наличии некоторого опыта главный вопрос к книгам о паттернах: "а зачем такие сложности и почему не сделать напрямую?". Лечится только шишками на лбу.
Smenov, насчет "неуловимых Джо" вы неправы.
TotalCommander и FileZilla хранят пароли к FTP не зашифрованными или зашифрованными тривиальным образом.
Имеем волну утечек паролей через вирусню, специально натасканную на эти цели.
Хранилище паролей в браузере существует сто лет, есть у каждого, и многие им пользуются.
Случаев утечек из этого источника я лично не знаю.
Хотя, согласитесь, это не "Джо", а вполне себе лакомый кусочек...
Smenov, не пользуюсь облаками. Но подозреваю, что описываемой вами схемой будет либо весьма неудобно пользоваться, либо она будет доступна любому, кто возьмет с вашего стола ваш смартфон.
Впрочем, возможен и третий случай - когда ее надежность и удобство будут аналогичны встроенному в браузер решению. Правда, для этого случая я не вижу смысла пользоваться более сложной системой.
Максим Тимофеев, Пароли для говносайтов, собственно, вовсе хранить незачем.
Но есть сервисы, где навязывают хаотичные пароли - не лезть же за ним в криптоконтейнер каждый раз?
Есть сайты, затребовавшие нетривиальный пароль, но при этом не имеющие никакой самостоятельной ценности. В общем, "случаи бывают разные", и почему не пользоваться простыми (не скомпрометированными) решениями?
Ну, вы-то знаете, в каком формате должен быть ключ у каждой из этих настроек.
Храните все текстом и приводите к нужному.
То же самое вы будете делать в файлах или JSON-ом, просто создадите видимость сложности.
Если это действительно критично - в конце концов, добавьте четвертую колонку "формат".
Это же самый простой способ отдать их злоумышленнику. Собрать в одном месте. Наивно думать, что они защищены.
У вас есть какие-либо пруфы о случаях кражи паролей из этого "одного места"?
Исключим всякие КиПассы и прочие сторонние приблуды. В любом современном браузере есть менеджер паролей, позволяющий хранить их, зашифровав мастер-паролем.
Кто-нибудь когда-нибудь взламывал эту систему, чтобы считать ее ненадежной?
Идея вредная. Задающему такие вопросы НИКОГДА не поможет то, что он думает, что ищет.
Просто потому, что для реверс-инжиниринга нужен значительный багаж IT-знаний и опыта, а его явно нет совсем.
Продолжайте мучить программу как черный ящик, выискивая закономерность между входом и выходом.
Других возможностей у вас нет.
Конструктор - это функция, возвращающая экземпляр класса.
На хрена вам конструктор в классе, экземпляром которого вы не пользуетесь?
Сделайте статический класс с функцией, возвращающей массив, и не извращайте парадигмы.
gsur, это понятно. Я не особенно знаком с 1С, но 1С-Битрикс, выгружая файлы для Ёкселя, на самом деле жульничает - выдает не XLS, а HTML с другим расширением. Ёксель их открывает, как родные. А вот для парсинга, как мы понимаем, разница есть... если ваш клиент не пересохраняет их в Ёкселе.
Перехватывать и обрабатывать, если можешь.
Пробрасывать дальше, если обработать сам не можешь, а там есть, кому перехватить.
Не использовать вовсе, если в них нет необходимости.
В остальном - вы же не спрашиваете, как правильно работать с отверткой?
Инструмент есть инструмент, как вам надо - так и работайте.