Здравствуйте, SINED_, Вы писали:
SIN>Здравствуйте, lozzy, Вы писали:
L>>Каждый кейген — уникален. Посылка обрезка не будет иметь практически никакого смысла. Может тебе проще дать им список валидных ключей, а они будут выдавать их по мере поступления ордеров?
SIN>Мне хотя бы посмотреть на механизм получения полей, например, имени и фамилии, и выдаче ключа, а функцию генерации я сам напишу
Здравствуйте, SINED_, Вы писали:
SIN>Друзья! Кому не жалко, поделитесь PHP-скриптом для генерации ключа на Plimus? SIN>Мой e-maiL: Буду очень признателен!
Каждый кейген — уникален. Посылка обрезка не будет иметь практически никакого смысла. Может тебе проще дать им список валидных ключей, а они будут выдавать их по мере поступления ордеров?
Здравствуйте, lozzy, Вы писали:
L>Каждый кейген — уникален. Посылка обрезка не будет иметь практически никакого смысла. Может тебе проще дать им список валидных ключей, а они будут выдавать их по мере поступления ордеров?
Мне хотя бы посмотреть на механизм получения полей, например, имени и фамилии, и выдаче ключа, а функцию генерации я сам напишу
Не курю — говорят это вредно для легких. А я как раз легкий.
Здравствуйте, SINED_, Вы писали:
SIN>Огромное спасибо! Это то, что надо SIN>А можно ли протестировать всю конструкцию? Т.е. какой-то тестовый ордер, чтобы проверить правильное ли письмо генерируется покупателю?
Разумеется. В настройках продукта радом с полем "Buy Now URL" есть кнопка "Test order".
Здравствуйте, SINED_, Вы писали:
SIN>Здравствуйте, lozzy, Вы писали:
L>>Это вообщем-то все.
К сожалению, это не все.
У меня все застопорилось на echo $licenseKey;
Саппорт сообщил, что For example: you have a script written in asp called keyGen.asp that resides
on your website, the script takes the email address of the customer and
returns a key in the format of DDD — XXX
...
Your script would like the following:
Sub subName( yourVariableName )
{
your algorithm to make a unique id.
..
Response.Write(DDD — XXX)
}
Проблема в формате DDD — XXX. На уточняющий вопрос, где найти описание этого
формата или, по-крайней мере, как закодировать конкретный ключ ABCDEF1234567890,
они мне так и не ответили. На Plimus'e об этом ни слова. Google тоже не помог —
я не знаю куда рыть, web-programming'ом раньше не занимался.
М.б. кто-либо знает что это за формат? Я уже извелся в попытках его угадать.
Пробовал плоский текст, закавычивал, добавлял html-тэги, вставлял со всех сторон
переменную LICENSE_KEY... Тем не менее после каждого ордера получаю предупреждение
от alerts@plimus.com:
"The system was unable to automatically retrieve a license for this order,
please note that the customer has been advised he/she will be sent one shortly
directly from you.".
Ключи я отсылаю пока прямо со скрипта, но это имеет и свои негативные стороны —
если Plimus дернет мой кейген не по делу, то ключик уйдет безвозвратно
(сам-то он мог и не послать ключ из-за возникших на последней стадии покупки
неких дополнительных обстоятельств).
По вопросу кейгена подсказать не могу. Вернее, могу: если использовать Армадиллу, то хостить кейген вообще не нужно
T>Ключи я отсылаю пока прямо со скрипта, но это имеет и свои негативные стороны - T>если Plimus дернет мой кейген не по делу, то ключик уйдет безвозвратно T>(сам-то он мог и не послать ключ из-за возникших на последней стадии покупки T>неких дополнительных обстоятельств).
А вот по этому вопросу мне отвечал саппорт Плимуса. Дескать, дёрнуть-то они кейген дёрнут, но если ордер помечен как подозрительный, письмо с ключиком не уйдёт до момента проверки (обычно прозвона) покупателя.
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, Tide, Вы писали:
R>По вопросу кейгена подсказать не могу. Вернее, могу: если использовать Армадиллу, то хостить кейген вообще не нужно
T>>Ключи я отсылаю пока прямо со скрипта, но это имеет и свои негативные стороны - T>>если Plimus дернет мой кейген не по делу, то ключик уйдет безвозвратно T>>(сам-то он мог и не послать ключ из-за возникших на последней стадии покупки T>>неких дополнительных обстоятельств).
R>А вот по этому вопросу мне отвечал саппорт Плимуса. Дескать, дёрнуть-то они кейген дёрнут, но если ордер помечен как подозрительный, письмо с ключиком не уйдёт до момента проверки (обычно прозвона) покупателя.
Спасибо за оперативный ответ и ценную информацию на счет обстоятельств, как они дёргают.
Армадиллу я как-то тоже прикупил, но сейчас она у меня лежит-пылится.
Пробовал ею защищать разные свои поделки, которые продавать пока не не продаю,
но и фриварой пустить жаба давит — стабильность этих прог резко падала
(причем, я не злоупотреблял степенью защиты a la CopyMem-II).
И с другой стороны, защитой собственного изготовления я вполне удовлетворен.
Правда, писалась она до знакомства с регистраторами, поэтому поставка кроме
собственно ключа, включает и небольшой бинарник. А регистраторы такую поставку
не поддерживают (кроме, вроде, shareit, но он у меня редко используется,
и в переводе только его на http-keygen большего смысла я не вижу).
Ладно, буду надеятся, что кто-то таки поделится собственным опытом установки
кейгенератора для Plimus'a или просветит, что же это за формат такой DDD-XXX
R>По вопросу кейгена подсказать не могу. Вернее, могу: если использовать Армадиллу, то хостить кейген вообще не нужно
T>>Ключи я отсылаю пока прямо со скрипта, но это имеет и свои негативные стороны - T>>если Plimus дернет мой кейген не по делу, то ключик уйдет безвозвратно T>>(сам-то он мог и не послать ключ из-за возникших на последней стадии покупки T>>неких дополнительных обстоятельств).
R>А вот по этому вопросу мне отвечал саппорт Плимуса. Дескать, дёрнуть-то они кейген дёрнут, но если ордер помечен как подозрительный, письмо с ключиком не уйдёт до момента проверки (обычно прозвона) покупателя.
Кстати, на счет последствий дёрганья кейгена все не так однозначно.
Plimus рекомендует вставлять в регистрационное письмо тэг <LICENSE_KEYS>.
Текст этого письма, обрамленный стандартными предложениями Plimus'a,
выводится на экран покупателю после успешного процессинга карты.
Спинным мозгом чувствую (на это наталкивает явно неудачное решение дёргать
кейген без достаточных на то оснований, и, более того, отсутствие к.-л.
предупреждений об опасности самостоятельной рассылки ключей кейгеном),
что ключик (независимо от способа генерации) будет _всегда_ высвечиваться
в теле этого письма, нежели указанный тэг присутствует в его шаблоне.
Даже если отправка собственно письма задержана. Люди, сделав одну явную
глупость, обычно на этом не останавливаются. Чувствую, что придется
отказаться от автоматической рассылки ключей. По-крайней мере, до
прояснения этого обстоятельства.
Здравствуйте, Tide, Вы писали:
T>Кстати, на счет последствий дёрганья кейгена все не так однозначно. T>Plimus рекомендует вставлять в регистрационное письмо тэг <LICENSE_KEYS>. T>Текст этого письма, обрамленный стандартными предложениями Plimus'a, T>выводится на экран покупателю после успешного процессинга карты.
Нет, не выводится (как мне сказал саппорт, он показывается только в тестовом ордере для отладки).
Вот кусок из нашей переписки:
> Another question is: do you always show the content of generated email
> on the order completion page? This would cause the same problem.
*** The content of the confirmation email is only shown in test orders, when a real order is placed it will not show since the order may still be flagged
for manual revew and may prove to be fraudulent.
Note: The key is retrieved for each order placed, but since the instant notification URL is not called unless the order has been processed you may keep
track of which key was not provided by comparing the calls to the key generator with the calls for the instant notification URL if you need to retrieve
unused keys.
Здравствуйте, retalik, Вы писали:
R>Нет, не выводится (как мне сказал саппорт, он показывается только в тестовом ордере для отладки).
R>Вот кусок из нашей переписки:
R>
>> Another question is: do you always show the content of generated email
>> on the order completion page? This would cause the same problem.
R>*** The content of the confirmation email is only shown in test orders, when a real order is placed it will not show since the order may still be flagged
R>for manual revew and may prove to be fraudulent.
R>Note: The key is retrieved for each order placed, but since the instant notification URL is not called unless the order has been processed you may keep
R>track of which key was not provided by comparing the calls to the key generator with the calls for the instant notification URL if you need to retrieve
R>unused keys.
О, это отличная новость. Тогда кейген нужно прикручивать к вызову back-end engine
(он идет через POST) и не париться особо на счет DDD-XXX. Я этот вариант уже,
собственно, опробовал в самом начале, и он работает (только, естественно, ключ
Plimus'у не отдает). Однако хотелось большего. Я хотел на базе сгенерированного
ключа создавать уникальный линк на свой сайт, с которого юзер имел бы возможность
загрузки регистрационной инфо (вклюая бинарный файл), на случай, если письмо с сайта
и Plimus'a не дойдут (корявый мейл, особо усердный антиспам-фильтр, etc.).
Но, в принципе, пока можно обойтись и без этого.
Виталий, спасибо большое. Вы мне реально помогли.
Здравствуйте, Tide, Вы писали:
T>For example: you have a script written in asp called keyGen.asp that resides T>on your website, the script takes the email address of the customer and T>returns a key in the format of DDD — XXX T>... T>Your script would like the following:
T>Sub subName( yourVariableName ) T>{ T>your algorithm to make a unique id. T>.. T>Response.Write(DDD — XXX) T>}
T>Проблема в формате DDD — XXX. На уточняющий вопрос, где найти описание этого T>формата или, по-крайней мере, как закодировать конкретный ключ ABCDEF1234567890, T>они мне так и не ответили. На Plimus'e об этом ни слова. Google тоже не помог - T>я не знаю куда рыть, web-programming'ом раньше не занимался.
Господа, учите албанский! Ясно же написано "for example". Т.е. саппорт привел пример произвольного формата ключа, который ты мог бы использовать. Естественно они не ответили что это за формат. Представляю что они подумали
