Month: January 2017

Ui Router Ng2 1.0.0 Beta.4

Today’s 1.0.0-beta.4 release of ui-router-ng2 brings support for Ahead of Time compilation (AoT),
support for @ngtools/webpack lazy loading,
and much better integration with the Angular CLI.

This release includes more breaking changes than usual.
We are making an effort to call out more breaking changes that could potentially
break end user applications, even if the prior behavior was unspecified.

Changes in 1.0.0-beta.4

The 1.0.0-beta.4 is a major update, which includes many bug fixes and lots of new features.

Please see the release notes
for detailed information, including the BREAKING CHANGES.

Repository split

During the 1.0 alpha phase, we made the UI-Router core agnostic to AngularJS.
This enabled us to continue development of
angular-ui-router
while creating
ui-router-ng2
and
ui-router-react.
The ui-router-ng2 code augments the
ui-router-core
code adding Angular (2+) specific features and concepts, as well as integrating with the Angular lifecycle and DI system.

During the betas, both ui-router-ng2 and the angular-ui-router for ng1 were built from the same repository.
This seemed like a good idea at the time because it allowed PRs to a monolithic repository.
However, over time it became apparent that hosting both codebases together was not sustainable.
So, we split the repositories into:

  • http://github.com/ui-router/ng2: ui-router-ng2: UI-Router for Angular (2.0 and above)
  • http://github.com/ui-router/core: ui-router-core: UI-Router core
  • http://github.com/angular-ui/ui-router: angular-ui-router: UI-Router for AngularJS 1

This release of ui-router-ng2 is the first one built from the modular UI-Router repositories.
Going forward, the release schedules for AngularJS and Angular (2+) will no longer coincide.

For those of you using the ng1-to-ng2 hybrid adapter, stay tuned.
We will be changing the approach of the hybrid adapter to accomodate the different release cycles
of the AngularJS and 2+ codebases.

Angular CLI

Many users have been asking when we would support the Angular CLI and support Ahead of Time compilation.
Finally, ui-router-ng2 has full AoT support, and integrates nicely with the Angular CLI including AoT and Lazy Loading.

To use the Angular CLI and lazy loading, follow this pattern:

Add npm dependency to ui-router

Add ui-router-ng2 (and temporarily also add @angular/router):

npm install --save ui-router-ng2@1.0.0-beta.4 @angular/router

Add UIRouter to the root module

Add UIRouterModule.forRoot to the root NgModule’s imports in app.module.ts

export let ROOT_STATES = [];
export function routerConfigFn(router: UIRouter, injector: Injector) {
  // ... do router config
}
imports: [
    UIRouterModule.forRoot({
        states: ROOT_STATES,
        useHash: false,
        otherwise: "/home",
        config: routerConfigFn
    })
...

Generate a child NgModule

Use the CLI to generate a child module.
This is a nested NgModule which will be lazy loaded.

ng generate module admin

Create a top-level state as a Future State

A future state is a placeholder for a state that will be defined by a lazy loaded NgModule.
Define the future state in the parent module.
Append .** to the future state’s name, and supply a loadChildren string which points to the lazy NgModule.

In app.module.ts:

export let ROOT_STATES = [
    { 
      name: 'admin.**',
      url: '/admin', 
      loadChildren: './admin/admin.module#AdminModule'
    }
]

Create the final state in the child NgModule

When the child module is lazy loaded, it should fully define the state to replace the Future State placeholder.

In /admin/admin.module.ts:

export const ADMIN_STATES = [
  { name: 'admin', url: '/admin', component: AdminComponent }
]
@NgModule({
  imports: [ 
    UIRouterModule.forChild({ states: ADMIN_STATES });
  ],
  declarations: [ AdminComponent ],
})
export class AdminModule {}

Serve the app

You can now serve or build the app using angular-cli in either AoT mode or JIT mode.

ng serve -aot
ng build -aot --prod --sourcemap

Problems/Feedback?

If you have feedback or problems integrating ui-router-ng2 with angular-cli, please create an issue
in the ui-router-ng2 repo.

Angular Ui Router 1.0.0 Rc.1

We released Angular UI-Router 1.0.0-rc.1 today.
This release indicates that the APIs are not expected to change before the final release of ui-router 1.0.

This release includes more breaking changes than usual.
We are making an effort to call out more breaking changes that could potentially break end user applications, even if the prior behavior was unspecified.

Changes in RC.1

RC.1 is a major update, which includes many bug fixes and lots of new features.

Please see the release notes for detailed information, including the breaking changes.

Repository split

During the 1.0 alpha phase, we made the UI-Router core agnostic to AngularJS.
This enabled us to create
ui-router-ng2 and
ui-router-react
by augmenting the
ui-router-core
code.

During the betas, both ui-router-ng2 and the angular-ui-router for ng1 code were built from the same repository.
This seemed like a good idea at the time because it allowed PRs to a monolithic repository.
However, over time it became apparent that hosting both codebases together was not sustainable.
So, we split the repositories into:

  • http://github.com/angular-ui/ui-router: angular-ui-router: UI-Router for AngularJS 1
  • http://github.com/ui-router/ng2: ui-router-ng2: UI-Router for Angular (2.0 and above)
  • http://github.com/ui-router/core: ui-router-core: UI-Router core

This release is the first one built from the modular UI-Router repositories.

This release (1.0.0-rc.1) of Angular UI-Router is not accompanied by a release of UI-Router for Angular (2+)+.
Going forward, the release schedules for AngularJS and Angular (2+) will no longer coincide.

Upgrading

If you haven’t considered upgrading to UI-Router 1.0, now is the time to start planning.
There are some breaking changes listed, but the should be fairly minimal for the typical UI-Router application.
Please follow the migration guide when upgrading.

Implement an HTTP to HTTPS redirect

Implement an HTTP to HTTPS redirect

If you’re looking to implement an HTTP to HTTPS (SSL) redirect for your web application, you can now enable a feature directly on the load balancer instead of configuring it on your server. This significantly improves redirect performance and reduces the load on your servers.

To implement this change, you must be on the main page of your Load Balancer or Web Application Firewall configuration page, as shown in the sample image below. Then click the “options” pop-up beside the HTTP protocol (this feature is only available in the HTTP protocol, not TCP etc.). If you haven’t created this protocol yet, you’ll need to, plus once implemented, you’ll need to map it to your server’s private port and IP too.

http to https options dialog

Once the options window opens, you will see the HTTP to HTTPS redirect checkbox as shown below. Simply check it and save.

HTTP to HTTPS redirect

After saving, allow a few minutes for the change to propagate our network before testing.

The post Implement an HTTP to HTTPS redirect appeared first on Total Uptime®.

How to block specific countries from reaching your website or application

How to block specific countries from reaching your website or application

Total Uptime’s Cloud Load Balancer and Web Application Firewall support a feature to block entire countries from reaching  your website or application on a per-port basis. This is a powerful tool to stop unwanted traffic from getting anywhere near your servers or devices. When enabled, traffic that reaches our network will have the origin IP checked against the popular MaxMind GEO database. If the client/origin IP matches the country you’ve blocked, the user’s connection will be dropped.

To implement this feature, you must click on the config/pack from the left navigation in the Configuration Builder. This will bring you to the main screen of your config as shown below:

TLS editing step 1

Once there, you can now select the Options button (as shown above) for the port you wish to block traffic on. When you click on the options dialog, you will see a new window as shown below:

block countries

Now, simply select the countries you wish to block by using the right arrow to move them into the Blocked Countries box. When finished, click the Save & Close button to push the changes to our network. Within a few minutes, the change will take effect.

Don’t forget!  This setting is done on a per-port basis. So if you have more than one port you wish to block, you will need to do this for all of them.

NOTE: This feature is not supported with all protocols. HTTP, SSL, SSL_BRIDGE, TCP (and a few others), no problem! But it is not available with UDP, DNS and a couple others.

The post How to block specific countries from reaching your website or application appeared first on Total Uptime®.