[sword-devel] [bt-devel] Unlock Keys and Frontends
dmsmith at crosswire.org
Sun Nov 22 19:13:36 MST 2009
On Nov 22, 2009, at 7:45 PM, Troy A. Griffitts wrote:
> Well, how DO WE, or how SHOULD WE?
I guess both. I still don't like the implementation in JSword and want good advice. Our implementation will always accept a good key and sometimes reject a bad key. It does not engage the user to confirm the results.
So thanks for the suggestions.
> Currently the code at:
> in cipherfrm.cpp does this:
> mod->setKey("Ipet 2:12");
> tmpBuf = mod->StripText();
> mod->setKey("gen 1:10");
> tmpBuf += "\r\n\r\n";
> tmpBuf += mod->StripText();
> Memo1->Text = tmpBuf.c_str();
> Maybe we should just:
> for (module == TOP; !module.Error() && !module.getEntrySize(); module++);
> DM Smith wrote:
>> I'm curious as to how you select the excerpt? Do you spin across the
>> possible keys until you find one w/ content? For example, consider a
>> Greek text that's a fragment of a Pauline epistle. Or just the book of
>> John in translation of a new lang.
>> In Him, DM
>> On Nov 22, 2009, at 1:05 PM, "Troy A. Griffitts" <scribe at crosswire.org>
>>> Sorry for the typos.
>>> I also wanted to say, if an example of how to change the .conf file to
>>> add the user supplied CipherKey is desired, I can supply a concise code
>>> As far as user flow specifically for entering a key...
>>> In BibleCS, we show an excerpt from the module, with an edit box for the
>>> user to type their unlock code, with a [Try] button next to it. The try
>>> button sets the unlock code in the module and re-retrieves the excerpt.
>>> If the unlock code is correct, the user will see the unencrypted module
>>> excerpt, and they can proceed to hit an [Accept] button to continue.
>>> But again, obviously each frontend will creatively design their own
>>> mechanisms. I would just like to be sure we have _some_ easy way on
>>> each frontend for our users to know where to obtain and then enter these
>>> unlock codes.
>>> Troy A. Griffitts wrote:
>>>> With the recent influx of interest from publisher to make material
>>>> available for our software, I'd like to propose a new .conf entry, and
>>>> encourage frontend developers to polish their facilities for users to
>>>> supply unlock keys for a locked modules.
>>>> The .conf entry I'd like to propose for all locked modules is:
>>>> This would be a URL where to begin the unlock process: Purchase form,
>>>> CCAT user agreement form, whatever.
>>>> Thus the flow in a frontend installer might be to show locked modules
>>>> differently with a special lock icon next to each modules available for
>>>> install, when the module is selected for install, a popup box explaining
>>>> that a key is needed, and for obtaining the key to please visit the
>>>> following URL..., possibly even prompting at this time for the unlock
>>>> key. Obviously each frontend with be creative, as usual, but I believe
>>>> this is a missing, critical piece we need to supply to frontends, for
>>>> them to build a smooth flow for the user.
>>>> bt-devel mailing list
>>>> bt-devel at crosswire.org
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> Instructions to unsubscribe/change your settings at above page
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel