Rick Boardman

My feedback

  1. 206 votes
    Sign in
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →
    Rick Boardman commented  · 

    even using SQL Server I currently make CRUD style sprocs and in node.js basically pass-through the parameters to SQL Server. so in node.js I respond to route GET /api/some-collection by calling the sproc some_collection_get to return the full set. so the node.js really isn't needed.

    all my sproc are run full access but I create a user context by boiler plating with the following:
    -- refresh session and get security context
    DECLARE @sesNow AS datetime, @sesIsValid AS bit, @sesIsGuest AS bit, @sesIsVisitor AS bit, @sesIsMember AS bit, @sesIsSomeRole1 AS bit, @sesIsSomeRole2 AS bit, @sesIsSomeRole3 AS bit, @sesAccountId AS uniqueidentifier, @accIsRestricted AS bit, @accIsApproved AS bit
    EXEC [sp_SecurityContext] @sessionId, @sesNow OUTPUT, @sesIsValid OUTPUT, @sesIsGuest OUTPUT, @sesIsVisitor OUTPUT, @sesIsMember OUTPUT, @sesIsSomeRole1 OUTPUT, @sesIsSomeRole2 OUTPUT, @sesIsSomeRole3 OUTPUT, @sesAccountId OUTPUT, @accIsRestricted OUTPUT, @accIsApproved OUTPUT

    obviously it needs work as the "in roles" should be an array but you get the idea

    With that I can tailor the logic and the returned view

    Rick Boardman commented  · 

    If you provided a public access restAPI endpoint (that doesn't require the master key) that could take an email address and password and return a token (similar to permission token).. maybe call it authToken

    and the ability to expose stored procedures via rest GET (actually all rest CRUD would be nice) sending the authToken in the headers and make that authToken available in the context of the sproc

    then we can create single page applications purely in client side javascript without exposing a master key, without the need for a middle tier. inside the sprocs we could check the auth token against the users, verify specific security, return views specific to the role.

    it would also be nice if that authentication process allowed 3rd party authentication and simply stored the 3rd party token. if not then ok we can make a little middle tier simply to handle 3rd party and assign the token ourselves.

    you are so close to providing a true rest CRUD database accessible by a purely client single page application.

    Rick Boardman supported this idea  · 

Feedback and Knowledge Base