Starcounter
HomeDownloadDocsCommunity
2.3.1
2.3.1
  • Starcounter Documentation
  • Getting Started
  • Starcounter
    • Collapsing the Stack
      • Complexity and Scalability Tradeoff
      • The Future of Micro-Services
      • 10 Benefits of Collapsing the Stack
    • Integrated Database and Web Server
  • Hello World - Tutorial
    • Create a Database Class
    • Create a Real Time UI
    • First Interactive UI
    • Computed Properties
    • Expense Tracker
    • Cancel and Delete
    • The Next Step
  • Guides
    • Database
      • Database Classes
      • Data manipulation
      • Object Identity and Object References
      • Querying with SQL
      • Data Types
      • Relations
      • Inheritance
      • Sharing data
      • Database Configuration
      • Comparing Database Objects
      • Referential Integrity and Constraints
    • SQL
      • Identifiers
      • Path Expressions
      • Data operators
      • Joins
      • Aggregates
      • Comparisons and Logical Operators
      • Sorting
      • Fetch
      • Offset Key
      • Indexes
      • Literals
      • Query Plan Hints
      • Reserved words
      • Query for Database Classes
      • SQL Isolation Between Applications
    • Transactions
      • Short-Running Transactions
      • Long running transactions
      • Using Transactions
      • Running Background Jobs
      • Commit Hooks
    • Typed JSON
      • JSON-by-example
      • Code-Behind
      • Data Bindings
      • Callback Methods
      • Responding with JSON
      • Accepting JSON in Requests
      • Primitive Arrays and Single Value Types
      • Typed JSON Internals
    • Blendable Web Apps
      • Starcounter MVVM
      • Palindrom
      • Client-Side Stack
      • Sessions
      • HTML Views
      • App Shell
      • Web Components
      • View Attaching
      • View Composing
      • HTML Compositions
      • HTML Views Blending Guidelines
      • Avoiding CSS conflicts
      • Debugging
    • Network
      • HTTP
      • Internal Self Calls
      • Middleware
      • Anonymous or Substitute Handlers
      • URL Aliases and Redirects
      • Network Gateway
      • Static File Server
      • External HTTP Calls
      • WebSocket
      • Avoiding URI conflicts
      • TCP Sockets
      • UDP Sockets
    • Publishing Apps
    • Working with Starcounter
      • Release Channels
      • Starting and Stopping Apps
      • Administrator Web UI
      • Star CLI
      • StarAdmin CLI
      • StarDump CLI
      • Working in Visual Studio
      • Error Log
      • Using HTTPS on NGINX
      • Using HTTPS on IIS
      • Run Starcounter in Production
      • Weaver
      • Investigating App Crashes
      • Configuration Structure
      • Database Refactoring
      • Using Unload/Reload to Modify Database Schema
      • Kernel Questions and Answers
      • Log Files
  • Cookbook
    • Attach an HTTP Request to an Existing Long-Running Transaction
    • Cookie-Based Authentication
    • Timestamp on Object Creation
    • Creating Strongly Typed JSON Collections
    • Migrating From 2.2 to 2.3+
    • Multiple Pages
    • Icons
    • Proposed Project Structure
    • Acceptance Testing with Selenium
    • Requesting a User to Authenticate
    • How to delete unused tables and columns
Powered by GitBook
On this page
  1. Cookbook

Requesting a User to Authenticate

PreviousAcceptance Testing with SeleniumNextHow to delete unused tables and columns

Last updated 7 years ago

To separate the concerns, your app should not directly deal with user authentication. Rather than that, it should have a view that blends in an authentication view from another app that deals with that.

Below instruction shows how to provide an authentication notice that blends in the authentication form from the app.

When your app decides that the view cannot be presented without authentication, it redirects to its own "Unauthenticated" view. For example: /your-app/partial/unauthenticated?return_uri={?}

if (!IsSignedIn()) {
    return Self.GET("/your-app/partial/unauthenticated?return_uri=" + getURI);
}

The getURI is the URI requested in the original GET request.

Then define a new handler for the "Unauthenticated" partial.

Handle.GET("/your-app/partial/unauthenticated?return_uri={?}", (string returnURI) => 
{
    return new UnauthenticatedPage();
});

The "unauthenticated" view model could be associated with a "Unautheticated.html" which defines a warning message about not being authenticated. The main purpose for this partial is to provide the mapping to the authentication view coming from the app using a predifined token.

{
  "Html": "/people/viewmodels/Unauthenticated.html"
}
using Starcounter;

namespace Your-App 
{
    partial class Unauthenticated : Json 
    {
    }
}
<template>
    <template is="dom-bind">
        <div>
            <iron-icon icon="icons:warning"></iron-icon>
            <label>You need to be signed in to use People.</label>
        </div>
    </template>
</template>

It should be mapped to a token userform-return, which is understood in other apps

    Blender.MapUri("/your-app/partial/Unauthenticated?return_uri={?}", "userform-return");

This message should be defined inside "Unauthenticated.Html" file which has to be set as the Html property for "unauthenticated" partial view.

That view is clever! Depending on SignInFormAsFullPage setting it will decide whether to display the login form right in this view, or redirect to a standalone page that only has the login form.

If app is not running, the user will only get a message about not being authenticated.

But if app is running, it shows its own view blended with the "Unauthenticated" warning message from the "Unauthenticated.Html" file.

You can have other apps than that do something in this view, but they will be competing for attention.

After successful log in, app redirects back to the return_uri in your app, so you can present to originally requested view.

SignIn
SignIn
SignIn
SignIn
SignIn
SignIn