Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Solution architecture

Jonathan Parker edited this pageJan 6, 2018 ·23 revisions

Solution architecture

The allReady application is implemented as a Visual Studio 2017 solution that contains two projects: an ASP.NET Core project that serves the web site and admin portal, and a cross-platform Cordova app project. The web application also exposes REST APIs used by the mobile app to access data.

Web Application

AnASP.NET Core web application provides the front-end web experience for volunteers accessing the allReady web site and the portal used by administrators. The site is powered by ASP.NET Core 2.0 using .NET Core 2.0. Here's the landing page for the web site:

allReady web portal

The web site relies on the following frameworks:

REST APIs

The same ASP.NET Core project also exposes a set of Web APIs which are part of the MVC framework. These REST APIs are used by both the web site and the Cordova mobile app.

Data layer

Data is stored in a database that is accessed by the ASP.NET application using Entity Framework Core 2.0.

Cloud services

The allReady web project is designed to be hosted in Microsoft Azure. The following services are used by this application when running in Azure:

Authentication

Authentication of web site mobile app users leverages OAuth 2.0 with credentials from external authentication providers such as Facebook, Twitter, Google or Microsoft. Users can use their existing social media accounts to sign into the web site or mobile app. For more information, seeEnabling authentication using external providers.

Cross-platform mobile app

The mobile app project was added to the allReady solution as aVisual Studio Tools for Apache Cordova project.

allReady mobile app

The client app relies on the following frameworks:

The app accesses theWeb API exposed by the web app for data access.

Users can sign-in with supported social providers such as their Facebook, Twitter, or Microsoft. You must configure each of these providers for the mobile app separately, as described in the next section.

Get started with the allReady solution

This section will help you get up-and-running with the allReady solution.

Prerequisites

You will need several prerequisites in order to run the allReady solution locally. Please see thePrerequisite Install Guide for details on what to download, install and configure to get started.

You will need the following to be able to run the allReady solution in Azure:

  • An active Microsoft Azure account to deploy the web app. You can sign-up for a free trial of Azurehere.

Configure the web project

The AllReady project relies on configuration settings at runtime, such as whether to use a local database or an Azure SQL Database for data storage, whether to load sample data, default accounts information, and credentials for connecting to other services. These setting values can be stored in the project's config.json file. However, doing this makes it easier to accidentally expose secrets. ASP.NET 5 includes a secrets manager tool, and you should instead use this to locally store settings in your user account. When you publish the project to Azure Web Apps, you will need to set these same values as app settings in your web app.

Note: currently the codebase does not include any 'secret' values in configuration. Since we deploy both a dev and live site for this project via HTBox, we will configure 'production' values for testing and production environments. Additionally, we are working on how to best support open development with identity providers listed below for all contributors and will update this information when a full solution is found.

Configuration settings are accessed at startup using theConfiguration property, which implementsMicrosoft.Framework.Configuration.IConfiguration. The following example gets the value of theInsertSampleData field that is a child of theData node:

Configuration["Data:InsertSampleData"]

These topics show you how to use the secrets manager for app settings when running locally and how to add app settings in your web app in the Azure portal:

The following app settings are used by the project.

General settings

These settings control how the web app stores and seeds data:

Key valueDescription
General:SiteBaseUrlUsed when creating links (when composing emails). Set by default as localhost:48408 but should be overridden in deployments.

Data settings

These settings control how the web app stores and seeds data:

Key valueDescription
Data:DefaultConnection:ConnectionStringThe local DB connection string. This setting is required to run the app locally.
Data:InsertSampleDataWhentrue, seed data is loaded into the data store.
Data:InsertTestUsersWhentrue, test user accounts are created on start-up.
Data:Storage:AzureStorageThe Azure Storage service connection string.

Settings inbold should be stored in the secrets manager.

Authentication settings

These settings are the credentials for the app registrations of the social media platforms supported for authentication:

Key valueDescription
Authentication:Facebook:AppIdThe ID of the Facebook app registration. For more information, seeRegister your apps for Facebook
Authentication:Facebook:AppSecretThe shared secret for the Facebook registration.
Authentication:Twitter:ConsumerKeyThe consumer key of the Twitter app registration. For more information, seeRegister your apps for Twitter
Authentication:Twitter:ConsumerSecretThe shared secret for the Twitter consumer key.
Authentication:MicrosoftAccount:ClientIdThe client ID of the Microsoft account app registration. For more information, seeRegister your apps for Microsoft account
Authentication:MicrosoftAccount:ClientSecretThe shared secret of the Microsoft account registration.
Authentication:Google:ClientIdThe client ID of the Google account app registration. For more information, seeRegister your apps for Google
Authentication:Google:ClientSecretThe shared secret of the Google account registration.
All of these settings should be stored in the secrets manager.

Connected service settings

The following settings enable the web app to connect to other services:

Key valueDescription
ApplicationInsights:InstrumentationKeyThe instrumentation key used by Application Insights.
Authentication:Twilio:SidThe ID the Twilio account to use for voice or SMS. For more information, seeHow to use Twilio for voice and SMS capabilities from Azure
Authentication:Twilio:TokenThe authentication token for theTwilio account used to send email.
Authentication:Twilio:PhoneNoThe phone number to display in a Twilio voice or SMS.
Authentication:SendGrid:UserNameThe username of theSendGrid account used to send email.
Authentication:SendGrid:PasswordThe password of the Microsoft account app registration.
Authentication:SendGrid:FromEmailThe email address that appears as the sender when users receive notifications.
Authentication:MicrosoftAccount:ClientSecretThe shared secret of the Microsoft account registration.

All of these settings should be stored in the secrets manager.

Configure the mobile app project

The URL of the AllReady web site is set in thedomainUrl variable in the /www/app/services.js file.

Run and test locally

Once you have set the required settings either in the config.json file or in the secrets manager, you can run and locally debug the projects. If you have not yet created a SQL Database in Azure, you should useData:DefaultConnection:LocalConnectionString as theconnectionStringPath value in Startup.cs.

Currently there are hardcoded user accounts for limited testing (this will of course be changed soon) For now:

Deploy to Azure

The AllReady project is designed to run hosted in Azure. The following sections describes the steps needed to get the AllReady web app running in Azure as you develop. Note that App Service Mobile Apps are currently available in theAzure Preview Portal.

Note: Again as with config, we will be hosting test and production instances of the application in the near future for tester contributors looking for instances of the application to test against and for others to reference. The instructions here are for self hosting in your own trial instance, if you choose, during development. However-- our goal is for all development to be able to be performed locally with alternatives or emulators for the online pieces.

Create an Azure Web app

To publish the AllReady project to Azure, you must first create a new web app in an Azure App Service environment. To learn how to do this, seeHow to Create a Web App in an App Service Environment.

Once you have created your web app, you must create the required app settings. To run the site, you must create a connection string setting forData:DefaultConnection:AzureConnectionString. To learn how to do this, seeConfigure web apps in Azure App Service.

Create SQL Database

The next step is to create a new Azure SQL Database. To learn how to do this, seeCreate your first Azure SQL Database. Once you have created your database in Azure, make sure thatData:DefaultConnection:AzureConnectionString is set as theconnectionStringPath value in Startup.cs.

Note: If you have created a firewall exception for your local computer, you can use this connection even when running on a local machine. For more information, seeStep 5: Configure the firewall.

Publish to Azure

Once you have your web app configured, you can publish the project to Azure. For more information, seeDeploy a web app in Azure App Service.

Clone this wiki locally

[8]ページ先頭

©2009-2025 Movatter.jp