Pablo Castro: Astoria Data Services

The Discussion

• 

  So this seems to be a mix between web services and RSS?

• 

  Very cool.  A lot like DNS (and we know that is good model) for data.  I land on mostly on the object side of things, so if .net lib takes care of all the uri goo for me, this we be fantastically great.  Love the hosting idea.  Been a big supporting of ms doing that.  Hope they stay and expand that idea.  Office live model sounds natural for this.  Free for N MB, $x for 500MB, etc.  Current Office live packages should include this ability as value add to respective packages.  Nice^2.

• 

  This would be cool a few years ago. I feel like Goldilocks after eating really bad porridge and trying-out a couple of f-up beds. The first bed was made out of a framework that wasn't very extensible. The second bed was made out of a framework that was too extensible. Meanwhile, the bears are in the back yard, smoking, dancing, and speaking in strange tongues. Little did I know, the bears purchased the house from the Winchester's. Most of the doors are fake and the stairs lead to nowhere.

• 

  JoshRoss wrote:

  This would be cool a few years ago. I feel like Goldilocks after eating really bad porridge and trying-out a couple of f-up beds. The first bed was made out of a framework that wasn't very extensible. The second bed was made out of a framework that was too extensible. Meanwhile, the bears are in the back yard, smoking, dancing, and speaking in strange tongues. Little did I know, the bears purchased the house from the Winchester's. Most of the doors are fake and the stairs lead to nowhere.

  
  
  huh?  I lovz me a smoking and dancing bear as much as the next guy, but what the hell does this mean?

• 

  There are many half-(I need to watch my language) frameworks, which do the same thing in a different way.  Why even bother inventing a new one, unless it does something amazing?  Here are some requirements for an amazing framework:  Secure, Consistent, Reliable, Extensible, and Fast.
  
  In addition, it needs end-to-end debugging, intellisense, and most importantly, a design that takes in account its own obsolescence.

• 

  JoshRoss wrote:

  

  There are many half-(I need to watch my language) frameworks, which do the same thing in a different way.  Why even bother inventing a new one, unless it does something amazing?  Here are some requirements for an amazing framework:  Secure, Consistent, Reliable, Extensible, and Fast.

  In addition, it needs end-to-end debugging and intellisense. 

  
  
  Isn't that what this is?  Have not used this product yet, but as a client library, you get the VS intellisense automatically.  And you get the end-to-end debugging already built into VS platform.  You could set break points in the client, in the middle tier and even in the DB managed procs if you need. 

• 

  In full disclosure, I have not used it either.  However, I have used a few other middle-tier frameworks.  It is difficult to get this right.  From the video, it looked like a pet project.  And Pet projects do not seem to stick around for too long.

• 

  Very cool.  I always really enjoy Pablo and the things he demos.  His enthusiasm is infectious. This looks great, but I'd much rather have him pushing Entity Framework out the door than focusing on the next thing.

• 

  I have to pause and ask.  Why do I need this?  It seems like technology in search of a solution.   I have some security concerns as well with Astoria. 

• 

  Arturo wrote:

  I have to pause and ask.  Why do I need this?  It seems like technology in search of a solution.   I have some security concerns as well with Astoria. 

  
  
  Hi Arturo,
  
  Here are some resources that hopefully will help clarify the scenarios we're going after with this technology.
  
  Overview document:
  http://astoria.mslivelabs.com/Overview.doc
  
  Mix 2007 presentation:
  http://sessions.visitmix.com/default.asp?year=All&event=1011&sessionChoice=2011,2012&sortChoice=4&stype=asc&id=1573&search=XD006&rsscheck=rss
  
  We do, of course, design things top-down; we start with application scenarios and go from there.
  
  Regarding security concerns, could you be more specific? I'd be really interested in hearing them so that I can either elaborate on how we think about specific security aspects, or add them to the list of things to sort out if I haven't heard of/thought of the issue before.
  
  Thanks,
  -pablo
  
  

• 

  How can you Tamperproof URIs for CRUD operations? What about the Cross site request forgery problem? How do other REST implementations deal with this? Will Astoria go through a standardization process like WS*? This should be Secure and Simple. Because there are existing solutions that are secure or simple, but not both.

• 

  I would imagine that you would need a service that produced and consumed one-time-use tokens. [EDIT] On second thought, row level permissions would work just fine. If it wasn't supported by the database, you could roll your own solution. Each webUser could be in a table with a permission +C+R+U-D say, a table name, and a primary key. Every sqlCommand would have something appended on the end. like select * from customers where city = 'Palm Beach' and customerID in (select primaryKey from webUsers where permission like '%+R% and webUserId='@webUserID') and (select primaryKey from webUsers where permission like '%+R% and webUserId='@webUserID') not null

• 

  JoshRoss wrote:

  How can you Tamperproof URIs for CRUD operations? What about the Cross site request forgery problem? How do other REST implementations deal with this? Will Astoria go through a standardization process like WS*? This should be Secure and Simple. Because there are existing solutions that are secure or simple, but not both.

  
  
  Not sure what you mean by tamperproof. Do you refer to protecting the URIs themselves? Or protecting the app from users creating their own URIs? The Astoria CRUD interface is no different from a regular website in some sense. In a "typical" application, at some point you fill up some fields and click "submit", which causes an HTTP POST. Anybody can see that URL and send a POST to it. The server-side code has to make sure you had the rights to do so (even if your webpage wasn't used to submit the request), and that the operation makes sense for the app. Astoria entry points have similar requirements; you have to indicate the authorization requirements, and you have to think about the consistency rules that apply to any side-effecting operation that you expose through the interface.
  
  Regarding cross-site request forgery, Astoria does some now, and you can expect more to come. First, HTTP GET requests are non-sideffecting by default (unless you introduce side-effecting operations explicitly). Doing cross-site non-GET requests is much harder. We'll also probably apply the usual techniques such as requiring special HTTP headers to make sure even more that the request is coming from an allowed site.
  
  It's really early to talk about standarization. We'll see how things turn out. I think that the web development community in general (including ourselves) still has a number of things to sort out in the HTTP (REST-style) space.
  
  -pablo
  

• 

  JoshRoss wrote:

  I would imagine that you would need a service that produced and consumed one-time-use tokens. [EDIT] On second thought, row level permissions would work just fine. If it wasn't supported by the database, you could roll your own solution. Each webUser could be in a table with a permission +C+R+U-D say, a table name, and a primary key. Every sqlCommand would have something appended on the end. like select * from customers where city = 'Palm Beach' and customerID in (select primaryKey from webUsers where permission like '%+R% and webUserId='@webUserID') and (select primaryKey from webUsers where permission like '%+R% and webUserId='@webUserID') not null

  
  
  We are still looking at the proper authorization model, including finding the appropriate authorization granularity.
  
  I agree that instance-level security is interesting, particularly from the application building perspective; however, making it fast is difficult, and making it work over arbitrary stores is not always possible.
  
  As we think about this I'll try to post on my blog on the various thoughts/approaches we consider. If you have input on the topic, I'd love to hear it.
  
  -pablo
  

• 

  Sorry about the last two posts, they should have combined into one.   Going with the idea of tamperproof URIs, I was more concerned with users modifying them or having them called multiple times.  Since the endpoints are complex entities, it is difficult to know how some, arbitrarily created, command could cascade an update or delete.  

  When I looked through the documents on the site, which could pertain to CSRF, I did not see the reference to additional required metadata in the headers to do non-get requests.  Right now, it is difficult to write secure web applications when there are so many steps in the pipeline that cannot be trusted.  It is amazing how many parts of a web request can be altered with a little JScript.  As far as security goes, you are only as secure as your weakest link. 

  As for security granularity verses speed.  If someone were going to be publishing these entities, it would be good to include a tool that would let them know what information could be exposed by doing so.  Maybe this tool already exists; I just have not seen it yet.  For example, if I had an Customers-Orders object exposed to let customers view their orders.  Who knows what the security is set to and what assumptions the developer makes?  It would be cool to see what information is available anonymously and what information is available to any authenticated user.  At that point, the program could offer guidance to reduce the surface of the exposed object.  It could do this by adding granularity or refactoring the object.
  
  On another side note, do you remember Microsoft English Query?  It was an application that sat between the user and the database.  You could ask it questions, or at least try to ask it questions.  It would then try to answer it.  The biggest problem was that people were and are bad at asking questions.  I wonder if any of the entities programmers had a chance to learn from the mistakes of that project.  Albert Einstein once said, “Make everything as simple as possible, but not simpler.”
  
  
  

• 

  staceyw wrote:

  

  JoshRoss wrote: This would be cool a few years ago. I feel like Goldilocks after eating really bad porridge and trying-out a couple of f-up beds. The first bed was made out of a framework that wasn't very extensible. The second bed was made out of a framework that was too extensible. Meanwhile, the bears are in the back yard, smoking, dancing, and speaking in strange tongues. Little did I know, the bears purchased the house from the Winchester's. Most of the doors are fake and the stairs lead to nowhere.

  
  
  huh?  I lovz me a smoking and dancing bear as much as the next guy, but what the hell does this mean?

  
  Check out the Winchester House here.  I got to tour the place while at SD West this year.

• 

  I wonder whether you have run into Fielding's dissertation on RESTful architectural style. Some of the concepts you are presenting fit very well with that style.
  I have been conceptualizing an architecture based on RESTful style