Overview of new functionality in Nov 4 update

Coordinator
Nov 5, 2014 at 6:48 PM
New in Nov 4 Release

Hi fellows
There are a lot of changes pushed yesterday. Many internal improvements, projects are reorganized/renamed/refactored.
  1. Set of standard modules in Vita.Modules assembly expanded quite a bit. There is a Logging folder with several modules:
    • ErrorLog - error log table and service; existed before, not much new
    • DbModelChangeLog - logs all Db model change scripts (DDL SQLs) applied with automatic model updates
    • OperationLog - when enabled, logs all executed SQLs (selects and updates) plus all log messages written by the application code (using session.LogMessage method)
    • TransactionLog - creates a log record for every database transaction (set of create/update/delete operations); tracks date/time and identity of the user; plus optionally records list of entities/primary keys updates. This change log might be used for database synching - can easily produce a set of all changed database records since given date. Also provides a facility for adding tracking fields to any external entities recording created/updated transaction ID (similar to UpdateBy, UpdateDateTime columns often found in tables in database models). See BookStore sample for an example of such extension in BooksEntityApp file: tracking columns are added to Book and BookReview tables.
    • IncidentLog - for logging special incidents and possibly setting monitoring triggers for repeated events. For example, failed login attempts are recorded, and you can install a trigger that disables login for 10 minutes after 3 failed attempts within 1 minute. This is a protection from automated dictionary attacks. See BookStore sample app for an example of this trigger.
    • WebCallLog - logs all web calls - URL, HTTP Verb, request/response bodies and headers, SQL log, request processing time. Can be setup to log only basic information for no-trouble calls, but it automatically escalates to detail level in case of exception to record all available information in case of error. This log is completely handled by WebMessageHandler (HTTP handler) in Vita.Web assembly. All you need to do is add this handler in HTTP pipeline, and logging is handled automatically.
    • Login module writes a LoginLog - all events related to logins (user login/logout, login failure, password reset, etc)
  2. Other new or improved modules in Vita.Modules assembly.
    • Login module has a number of improvements; one is already mentioned trigger to disable login after several failed login attempts with short period of time. Other features - login workflow for multi-step processes like 2-factor authentication, full password reset process, email confirmation, etc. ILoginService.Login method now returns LoginResult object that contains extended login information. In addition to basic Success flag (identifying successful login), it contains some extra info - pending actions like "need to setup secret questions", or need to confirm through 2Factor process. Your login code can react appropriately.
    • DbInfo module - creates a table with a single record that contains some essential information about the database (DbModel version, installation type, etc). The installation type column identifies a database as Dev, Staging or Production. One use of this field is to switch db model updates, depending on environment type. For development installations, the db schema can be updated automatically from code; for production database the automatic update is disabled - DB schema/model should be updated only by system admin, by carefully applying DDL SQL scripts to production database. These scripts are now generated internally and can be exported by vdbtool (command line tool) - this export is not there yet in the tool, but coming soon.
    • PersistentSession module - supports persistent session, primarily for web applications. Integrated with Web API stack through Vita.Web classes. Allows to avoid relying on ASP.NET session facility, which might difficult to use in restricted environment of Web Api data service applications.
For all these logs, to see how they work just run unit tests and then explore the tables using SQL Management Studio.
: One thing definitely missing for all these logging tables is a viewer/browser, preferrably web-based - this is coming, some day hopefully soon. I'm just not good at UI, that's the only reason it's still not there.
Coordinator
Nov 5, 2014 at 6:51 PM
(continued)
  1. Some improvements in Authorization setup and Secure session creation. Now there's an event in Authorization service UserRolesLookup when service requests from the app to give back the list of user roles. Hook to it in EntityApp class, and then opening secure session is trivial. Authorities (compiled user role sets) are double-cached inside authorization service (by UserId and by role list). See BookStore app for an example. It also seemlessly works in the Web data service - see service example. For BookStore authorization roles setup, there are now two separate roles instead of WebVisitor - Anonymous (web visitor who is not logged in as user) and Customer (logged in user).
  2. Building search queries - greately simplified, with PredicateBuilder helper class. See BookSearch method, with Web service method implementation - multiple search parameters, all optional, with order-by and paging parameters.
  3. Exceptions and client faults. Completely refactored exception handling. Now there is a ClientFaultException (former ValidationException) which can contain multiple faults. "Client" in this context means user or Web client (Angular app in the browser). The really cool thing is that handling client faults is integrated into Web components in Vita.Web dll, so if your service method or biz logic code detects input errors (missing value or value out of range), it throws ClientFaultException which will be caught by the handler in the WebMessageHandler and translated into BadRequest response to the client, with all faults serialized as Json in the message body. In AngulaJs client app, a simple interceptor for a service would handle the response placing error messages next to corresponding controls (each fault contains a tag identifying control/value name). See TestClientFaults method in unit tests for a demo code.
  4. Integration with ASP.NET Web API stack. Vita.Web assembly contains a number of classes (handlers, attributes and even a base API controller) that allow easy integration of VITA's functionality into a data service. There is a separate Web data service project Vita.Samples.BookStore.DataService - see it for an example of RESTful data service implementation and integration. The primary target app type I have in mind for this type of service is either RESTful public data service, or a single-page web app, with client-side page construction/manipulation (AngularJS) that requests only json data from the server. That's the app we are building at my day-time job, so naturally the functionality is geared towards this scenario.
    You can easily imlement different authentication schemes (with/without server sessions), with authentication token or cookie, plus CSRF token. BookStore data service uses authentication token in request header - the token is returned to the client after successful login.
  5. Refactored and straightened up the arrangement of "contexts". Now it's a bit more logical and better integrated with each other. EntitySession (a mini-context in itself) - references OperationContext, a container for values describing a series of operations. For web apps, the OperationContext is created for a single web call. OperationContext references UserInfo - a small object identifying current user (UserId, UserName and Kind). User Kind is: Anonoumous, AuthenticatedUser or System (internal, all powerful, no security checks identity to be used internally). OperationContext can also point to WebCallContext - a container for all info related to the current web call (URL, cookies, headers) plus provides a bridge to the future response; using WebCallContext you can set explicit HTTP status code for the response, add response headers or cookies. Plus there is a UserSession context - a when persistent session is used, this object holds information across multiple calls from the same user. UserSession is cached in memory and is automatically handled by PersistentSession module - you don't need to do much, it is automatically there when your controller code starts. OperationContext/WebContext is available in Request's properties, or directly as properties of a controller (if you use BaseApiController in Vita.Web).
  6. HttpClientWrapper - a wrapper around HttpClient, with lots of convenience features. This is primarily to use in .NET code that needs to access some external Web data service. And I use it extensively in unit tests. I really think that raw HttpClient is a pain to use directly, so I made this wrapper. One caveat - the wrapper is single-entry - it cannot make another request until previous is completed. The wrapper takes care of proper deserialization of responses, including handling BadRequest and reading client faults in the body and then rethrowing them as ClientFaultException in the client process.