Day 56 - Get back to work you rotten kids

by alex 28. March 2013 18:05

Today I'm refreshing and recollecting my thoughts on what needs to be done.

Programming tasks

Integrating the sales site with the production release manager

When someone makes a purchase on the sales site, their card will be billed and then they get an email with a download link. This download link is not good; the file it points to is rotting. I'm pushing new releases to a publicly accessible installation of Build Keeper. I need to integrate these two sites together, and it has to be easy.

There are two separate databases right now, one for the releases sub domain and another for the www sub domain. They each have their own user list management - they use a common library, but they don't share a data store so www.eisenhartsoftware.com users can't log in to releases.eisenhartsoftware.com.

If a visitor logs in to releases with a user account that is a member of the "Active subscriptions" group, then they can download releases.

Ultimately, the problem to solve is "How do I securely get context about a user's activity in Site A into Site B?" Specifically, in releases I need to know if an authenticated user (I don't care how they were authenticated, forms authentication, Facebook, Open ID, whatever) has purchased the software on www.

I have a few ideas to integrate the sites:

  1. Keep the user lists separate - 
    • Push credentials to releases via a web service, restful API or something and have it register a new user account and add the user to the "Active subscription" group. This solution would be difficult to make secure - there would probably be holes that an attacker could use to get access to my downloads. This solution would lead to issues with keeping password changes in sync since there are technically two separate accounts - the creation of the second one is streamlined.
    • Enable a federated security setup in releases to allow it to accept claims and credentials from www. A www user could then login to releases and releases would trust credentials from www. This would probably be a solid solution, but it would have a heavier startup cost because I would have a bit of learning to do. However, adding federated security is a feature that is in my future-wish-list item pool. This might require 3rd party certificates to sign communications. This solution avoids the password management issue from the previous example (because releases wouldn't have a password for the user) but other account details would be duplicated.
    • Expose the available downloads from releases in the www site via a restful API. This is another future-goal, but it doesn't resolve the issue that releases needs to have knowledge of a permission set for a www user.
  2. Create a shared user store
    • Re-architect how Build Keeper stores users. In the current DAL, all database tables exist in the same database. I could change the User Repository to connect to a second database - the www database or a new independent DB. This constitutes a product change.

 Or something else. I don't want to dwell on implementation details right now.

Finish product features

  • Searching
  • Form updates (documentation, tab order, appearance)

Advertising tasks

  • Finalize logo
  • Trademark logo
  • Put logo into the product and the product sales site
  • Update features page on product site
  • Review copy on the home page of product site and make no-brainer improvements

Tags:

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

About the author

Something about the author

Month List