Re: Disadvantages to peristing replication settings as text?

• Previous message: Darren Shaffer: "Re: Disadvantages to peristing replication settings as text?"
• In reply to: Darren Shaffer: "Re: Disadvantages to peristing replication settings as text?"
• Messages sorted by: [ date ] [ thread ]

Date: Wed, 1 Dec 2004 15:03:54 -0500

If you are talking about the eVB sample, I have actually used that signature
encryption concept for awhile now -- but only for the signature. I'll
revisit that for use here. My app does include a "Replication Settings" form
with some preset settings, but the last step was obviously to persist those
settings so the user would not have to re-enter their own each time. It
sounds like you have pretty much narrowed it down to the registry as the
best way to go for that, and I'm not keen on re-inventing the wheel, so I
will look at that option with more focus. Thanks again.

"Darren Shaffer" <darrenshaffer@discussions.microsoft.com> wrote in message
news:eZuDU571EHA.936@TK2MSFTNGP12.phx.gbl...
> Earl,
>
> I didn't realize you were building a product that includes replication for
> sale/distribution.
> Figured this was a scenario where you were building an internal IT project
> that just had
> branch offices/servers involved. In your ISV scenario, I would not embed
> credentials in code
> or in the database. I'd actually have the mobile app include a "settings"
> form where the
> end user can view/edit application configuration and the results are
> stored encrypted
> in the registry. I build a lot of MapPoint web service CF apps for
> distribution with
> rugged GPS devices and I use the following approach:
>
> 1. on install to device, I write a set of "starter" MPWS credentials to
> the registry in an encrypted format
> 2. my app has a Configuration form the allows the user to update those
> settings.
> 3. on initial run, the user must update their credentials to reflect an
> actual account with Microsoft.
>
> If you decide to go this way, there are a couple of great registry mgmt
> classes for CF that come
> with the sample code to Paul Yao's book on programming CF. The MSDN
> sample where
> signatures being captured are encrypted for transfer to a server is where
> I derived the encryption algorithm.
>
> -Darren
>
> "Earl" <brikshoe@newsgroups.nospam> wrote in message
> news:ODkC7l11EHA.2316@TK2MSFTNGP15.phx.gbl...
>> Sounds like you've thought a lot about this very topic Darren. Good food
>> for thought. Let me try to clarify this in my mind.
>>
>> "Embed them in the application ..." It almost sounds like you are saying
>> to distribute the settings on a per company basis. Let's say I sell 50
>> licenses to Company X and 30 licenses to Company Y, then each of these
>> companies get their own settings embedded? I love the idea for licensing
>> purposes, although that poses problems when you don't know what the IIS
>> and server settings are for each company.
>>
>> Encrypting and embedding in the registry is one thought I had in fact
>> considered. Still mulling that one.
>>
>> I will check out your configuration tool.
>>
>> A password-protected SQLCE database seems problematic, since the
>> replication settings are going to be -- again -- dependent on each
>> company's IIS and server settings (not to mention the publications that
>> may change on a daily basis).
>>
>> Thanks for the ideas. If you have anything to add to my concerns, I'd
>> love to hear it.
>>
>> "Darren Shaffer" <darrenshaffer@discussions.microsoft.com> wrote in
>> message news:%23wuzBlv1EHA.1300@TK2MSFTNGP14.phx.gbl...
>>> Earl,
>>>
>>> I think the big issues to consider in making your decision on this are
>>> updating the replication parameters to specific sets of distributed
>>> devices and (as you mentioned) security. Options to consider for
>>> getting the right set of replication parameters to the right set of
>>> devices include:
>>>
>>> 1 - embed them in the application and have different sets of devices
>>> take different CAB file app deployments depending on the version
>>> you want them to have
>>> 2 - write them to the device registry - you can also encrypt these for
>>> security purposes. your app can be written to encrypt and write the
>>> settings to the registry the first time it is executed and then clean up
>>> the
>>> file that contained the settings that was deployed in the CAB file.
>>> again, different CAB files are required for different groups of devices.
>>> 3 - look at an enterprise level device configuration management tool
>>> like www.soft360.com or wait for SMS2004 to reach release and
>>> manage the configuration of different groups of devices from a central
>>> point of control
>>> 4 - deploy the replication settings in a password-protected, encrpted
>>> SQL CE database that gets deployed with your application. read them
>>> from a table prior to the first subscriber pull.
>>>
>>> I'd steer clear of a text file or an XML (config.xml) file that holds
>>> the
>>> URL of the IIS server and authentication info - very insecure. To
>>> answer
>>> your other question - code to get/set values from a config.xml file is
>>> shorter and more standard than code to do so from a text file and at
>>> least for
>>> now, the average user cannot view the contents of an XML file on a
>>> PocketPC
>>> in PIE.
>>>
>>> -Darren Shaffer
>>>
>>>
>>> "Earl" <brikshoe@newsgroups.nospam> wrote in message
>>> news:Oq1owPq1EHA.3000@TK2MSFTNGP15.phx.gbl...
>>>> Contemplating how I want to store my replication settings (per site may
>>>> all differ). My understanding is that XML is slower to and fro, which
>>>> makes sense. I see a security issue persisting any passwords as text,
>>>> but otherwise, what am I giving up using text file over XML?
>>>>
>>>
>>>
>>
>>
>
>

• Previous message: Darren Shaffer: "Re: Disadvantages to peristing replication settings as text?"
• In reply to: Darren Shaffer: "Re: Disadvantages to peristing replication settings as text?"
• Messages sorted by: [ date ] [ thread ]