Re: Disadvantages to peristing replication settings as text?

From: Darren Shaffer (darrenshaffer_at_discussions.microsoft.com)
Date: 12/01/04

  • Next message: Earl: "Re: Disadvantages to peristing replication settings as text?" 
    Date: Wed, 1 Dec 2004 08:56:25 -0700

    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?
    >>>
    >>
    >>
    >
    >

  • Next message: Earl: "Re: Disadvantages to peristing replication settings as text?"

    Relevant Pages

    • Re: Ini File vs Registry
      ... How do you manage the settings? ... dollars in hacking the OS to introduce the concept of registry ... Hard to migrate app ... but increasingly desktop developers are fighting it out ...
      (microsoft.public.vc.mfc)
    • Re: Disadvantages to peristing replication settings as text?
      ... If you are talking about the eVB sample, I have actually used that signature ... encryption concept for awhile now -- but only for the signature. ... My app does include a "Replication Settings" form ... sounds like you have pretty much narrowed it down to the registry as the ...
      (microsoft.public.sqlserver.ce)
    • Re: Vista makes me crazy, please help.
      ... It's hardly complex to have the filename or the section name contain the user ID if that's necessary or to place the INI under the user's app data folders. ... The overhead of the registry index structure cuts into that but even if it still saves space it is a small advantage that is utterly swamped by the advantages of the individual files. ... There is some buffering on INI files as well and unless you are doing a LOT of reading and writing settings the speed just is not an issue. ...
      (microsoft.public.vb.general.discussion)
    • Re: Ini File vs Registry
      ... How do you manage the settings? ... dollars in hacking the OS to introduce the concept of registry ... Hard to migrate app ... with web apps and their no-install worries propositions. ...
      (microsoft.public.vc.mfc)
    • RE: Reg/INI Discussion from much earlier
      ... If it takes a noticable time to save the configuration data, you've either written the app wrong, or defined configuration data wrong. ... > in the event of an improper shutdown, the registry is NOT saved. ... > uncontrolable factor and the user wants to save his/her settings. ...
      (microsoft.public.vb.general.discussion)