SoCal Code Camp 2018 at USC on Nov 10-11

John Meeks
This November 10th weekend, SoCal Code Camp 2018 is coming to the USC campus.

SoCal Code Camp

The SoCal Code Camp is a great event to network with fellow developers in the Southern California area and learn something new. If you can make it out this weekend go support your local developer community with great sessions and prizes. And, it’s a FREE event.

DiscountASP.NET renews EU-US and Swiss-US Privacy Shield Certification

Takeshi Eto
In 2016 we achieved the EU-US Privacy Shield Certification and in 2017 we attained the Swiss-US Privacy Shield Certification. Both of these were new frameworks that emerged after the previous Safe Harbor Framework was struck down by an EU court.

privacy shield frameworkOctober is our renewal month and I’m happy to announce that we worked with our privacy management solutions partner, Truste, and successfully renewed both Swiss-US and EU-US Privacy Shield certifications. You can get more information on the Privacy Shield program at

Earlier this year there was a LOT of privacy policy updates due to the EU General Data Protection Regulation (GDPR) coming into effect in May 2018. So you may ask, why bother with the Privacy Shield Framework? That’s a good question that we asked ourselves too.

The GDPR is brand new and, while the agreement itself was finalized, its interpretation and its related business practices are still evolving. At this time there is no solutions provider, including our partner Truste, that offers an official GDPR certification. I haven’t seen any “GDPR certified” seals on any website out there. Let us know if you see anything like that.

But since there is an existing official certification process for the Privacy Shield Frameworks, we believed that it was important for us to renew our Privacy Shield status to demonstrate our commitment to customer privacy. I hope you agree as well.


October 2018 Web Application Gallery Updates

Ray Huang

Below is a list of our Web Application Gallery updates for October 2018.



  • DotNetNuke (DNN) Platform
  • Gallery Server Pro 4.4.3
  • Joomla 3.8.12
  • mediaWiki 1.31.0
  • Moodle 3.5.2
  • nopCommerce 4.10
  • phpBB 3.2.3
  • phpMyAdmin 4.8.3
  • Umbraco CMS 7.12.2
  • WordPress 4.9.8

3 Ways to Redirect HTTP to HTTPS and non-www to www in ASP.NET Core

Ray HuangIn support, we’ve been seeing a lot of issues with URL Rewrite in ASP.NET Core.  Core is a complete rewrite of .NET and so things have changed. In ASP.NET Core, URL Rewrite is no longer handled by the URL Rewrite module (web.config file) but is now served by URL Rewriting Middleware.

This basic tutorial shows you three ways on how you can implement URL Rewrite rules using the Microsoft.AspNetCore.Rewrite library.

Let’s start by creating an empty ASP.NET core application.  In Visual Studio 2017, go to File -> New -> Project… (Ctrl-Shift-N).  Select Web -> ASP.NET Core Web Application.  Name the application and click on OK to continue.

In the Project template window, highlight Empty and click OK to continue.

In order to use the Microsoft.AspNetCore.Rewrite library, we’ll need to add it using NuGet.  Go to Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution…  Under Browse, type in Microsoft.AspNetCore.Rewrite, highlight it, check the checkbox next to your project, and click on Install.

That’s it.  Now, you’re ready to add URL Rewrite rules to your website.  Here are the 3 methods.

Method 1 : web.config/.htaccess file

If you know nothing about how to use the new URL Rewrite Middleware libraries or need some time to learn it, then you’re in luck.  You can still use the good old URL Rewrite syntax from the web.config file.  Right click on your project, select Add -> New Item… (Ctrl-Shift-A), highlight Data under ASP.NET Core, and select XML File.  In this example, I will name the file RedirectToWwwRule.xml, click on Add, and add the following markup to the file:

    <rule name="CanonicalHostNameRule">
      <match url="(.*)" />
        <add input="{HTTP_HOST}" pattern="^www\.domain\.com$" negate="true" />
      <action type="Redirect" url="{R:1}” />

Make sure you replace “” with your domain name in both the pattern and url.  Highlight the XML file and make sure in the Properties window, you select Copy always in the Copy to Output Directory field.  Now open up the Startup.cs file, add a using Microsoft.AspNetCore.Rewrite; directive at the top and enter the following code in Configure method:

app.UseRewriter(new RewriteOptions()
   .AddIISUrlRewrite(env.ContentRootFileProvider, "RedirectToWwwRule.xml")

What this does is redirect the non-www version of the URL to the www version and redirect HTTP requests to HTTPS.  You could also have removed the .AddRedirectToHttps() method and included it the URL Rewrite rule in the XML file and that would have worked too.

What’s great about RewriteOptions() is that if you place a . after it, IntelliSense will show you the available methods that you can use.  You’ll notice an AddApacheModRewrite() method which means you can use the rewrite rules from a .htaccess file instead, providing great flexibility for implementing rules from different sources.

Method 2 : Regular Expressions and HttpContext.Request.Path

The second method is fairly straightforward using a regular expression to perform the redirect.  Add the following code to the Startup.cs file:

app.UseRewriter(new RewriteOptions()                
   .AddRedirect("^foo$", "bar")

What this does is exactly the same thing as above but performs an additional redirect if either of these URLs is entered:

This will redirect to:

Note that the AddRedirect() method evaluates the regular expression against the HttpContext.Request.Path, so if you need something more complicated, you’ll need to use the first or last method.

Method 3: Adding a Rule using a Class

The last method involves implementing a rule using a class.  Right click your project, select Add -> New Item… and add a class named RedirectToWwwRule.cs.  Replace the entire class with this code:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Http.Extensions;
using Microsoft.AspNetCore.Rewrite;
using System;

namespace URLRewriteSample
    public class RedirectToWwwRule : IRule
        public virtual void ApplyRule(RewriteContext context)
            var req = context.HttpContext.Request;
            if (req.Host.Host.Equals("", StringComparison.OrdinalIgnoreCase))
                context.Result = RuleResult.ContinueRules;

            if (req.Host.Value.StartsWith("www.", StringComparison.OrdinalIgnoreCase))
                context.Result = RuleResult.ContinueRules;

            var wwwHost = new HostString($"www.{req.Host.Value}");
            var newUrl = UriHelper.BuildAbsolute(req.Scheme, wwwHost, req.PathBase, req.Path, req.QueryString);
            var response = context.HttpContext.Response;
            response.StatusCode = 301;
            response.Headers[Microsoft.Net.Http.Headers.HeaderNames.Location] = newUrl;
            context.Result = RuleResult.EndResponse;

Then add the following code to your Startup.cs file:

var options = new RewriteOptions();
options.Rules.Add(new RedirectToWwwRule());

This does essentially the same thing as Method 1.

Many thanks to the folks at StackOverflow for supplying the sample code for the rule,  and I hope it helps the folks out there that are struggling with ASP.NET Core and URL Rewrite to get started.

Windows Server 2016 Hosting

Takeshi Eto Windows 2016 hosting with Internet Information Services (IIS) 10.x is available in our US-based data center. In the DiscountASP.NET Order form, you can select Windows 2016 for your O/S.

Any existing customers who wish to move their site(s) to the Windows 2016 hosting platform, please contact our technical support staff so we can schedule a migration.

Windows 2016 hosting


Orlando Code Camp – March 17th Seminole State College

John MeeksCalling all developers in the Orlando, Florida area, are you looking for something to do this weekend? Well, have I got just the right thing for you.

On Saturday, March 17th the Orlando Code Camp is taking place, and we are a proud sponsor of the event. We are always proud to support the developer community and these events. Come out and learn, network, and have fun.Orlando Code Camp

Google Now Blocking Ads in Chrome Natively

John MeeksStarting on Thursday, February 15th 2018, Google turned on what they call “Ad Filtering” for their Chrome browser. What that means is Chrome will now block ads natively instead of you having to install an ad-blocker extension to the browser. This all starts with Chrome version 64 and will affect Windows, Mac, Linux, Chrome OS, and Android. The iOS version of Chrome is Safari-based so it will not have the ad-blocking yet.

To come up with the guidelines on what is considered a “bad ad”,  Google worked with the independent organization Coalition for Better Ads and identified 12 ad types that they found were a poor user experience for visitors. These “bad ads” include pop-ups, countdown ads that restrict access to content until finished, auto-play ads, and large sticky ads.



If you display ads on your website:
To see if your site has ads that will violate these guidelines, you will need to have access to the Google Search Console for your site. Via the Search Console there will be a section marked “Web Tools”. Under “Web Tools” you will now have access to the “Ad Experience Report” which will give your site a Passing, Warning, or Failing status. If your site has yet to be reviewed, Google will not provide a status. Google will base your site’s status on a sampling of pages from your site on both desktop and mobile devices. If you are found to have offending “bad ads”, you will be given 30 days to correct the issue before Google acts to block ads on your site. Once you correct the ads in question, you will need to proactively request Google to re-review your site. If you take no action, or if the correction isn’t sufficient, after 30 days Google will block ALL ads from showing on the site – not just the offending ads. Chrome will then display a small notice to users when visiting your site that they have blocked the ads on your site with a link for more info.

This change is a major shift in how ad-blocking works. As of January 2018, Chrome’s user market share was 56.31% according to StatCounter, meaning that a majority of users on the internet will probably have an ad-blocker in place when they visit your site.



Google has also stated that their own ad networks, AdSense and DoubleClick, are not exempt from the ad-blocker and ads will be blocked if their own networks are in violation.

As a publisher you will need to be aware of the ads you are displaying on your site and what type of ads you are running. If you are a publisher who is reliant on advertising for any sort of income, just one “bad ad” that goes unfixed can have ALL the ads for your site blocked.

If you are an advertiser using display ads:
As an advertiser you need to be aware of the ads you are running, as well as the sites you are running them on. If you happen to have ads on a site that Google has decided to block in Chrome, you may be paying for advertising that no one will ever see.

You can read Google’s latest blog post on how this will all work in their Chromium Blog post “Under the hood: How Chrome’s ad filtering works“.

Life just got more difficult for publishers and advertisers…..

What’s Happening with Symantec SSL Certificates?

Michael PhillipsYou may have recently read one of the many confusing or seemingly contradictory articles about the Symantec vs. Google grudge match that’s been going on for some time now. If not, here’s the problem in a nutshell:

Google found a troubling number of bad SSL certificates issued by Symantec – bad meaning they had issued certs for and other high profile domains, but they issued them to people who were not Google, etc. Symantec said they were just test certificates used by internal staff, and they never left their four walls. But the fact remained that the certs were valid and could potentially cause a lot of trouble.

Google took issue with the fact that the certs were issued at all, and accused Symantec of sloppy housekeeping. They said to Symantec, “You need to prove to the world that you can clean up your act or we’re going to stop trusting your certs.” Symantec basically replied, “Oh, stop being so dramatic,” and Google said, “Oh yeah? We’ll show you dramatic,” and issued notices giving the exact dates when they would stop trusting the Symantec certs.



Okay, that’s not exactly how it went down, but it’s not that far from what really happened. Just imagine the above in barely polite corporate speak and you’re pretty much there.

In any event, you’re probably wondering what it all means if you have a Symantec SSL certificate (and if you use a RapidSSL, GeoTrust QuickSSL or GeoTrust True BusinessID certificate – which is what we issue – you are using a Symantec certificate).

The short answer: nothing.

It’s not likely that you’ll experience any problems related to the dust up.


Because Symantec sold their certificate business to a company that Google does trust. So the Symantec name will continue on, but the certificates will be issued by the “new” Symantec and trusted by Google. And unless you bought your current certificate a long time ago, it will be re-issued by the new Symantec when you renew it, so you won’t notice a thing.

Again, if you pay for your SSL certificate every year, this probably doesn’t apply to you, but just for the sake of completeness, here are the actual dates and what happens when:


For certificates issued before June 1st, 2016

The Chrome browser will no longer trust this certificate after March 15, 2018. In order to retain trust by the Chrome browser, you need to replace this certificate.

  • If the certificate expires before March 15th, 2018, you don’t need to do anything. The certificate will continue to be trusted by Chrome until it expires.
  • If the certificate expires after March 15th, 2018, but before September 13th, 2018, you can re-issue this certificate any time before March 15th, 2018.
  • If the certificate expires after September 13, 2018, you have to re-issue the certificate before March 15, 2018.


For certificates issued after June 1st, 2016

The Chrome browser will no longer trust this certificate after September 13, 2018.

  • If the certificate expires before September 13th, 2018, you don’t need to do anything. The certificate will continue to be trusted by Chrome until it expires.
  • If the certificate expires after September 13th, 2018, you have to re-issue the certificate before September 13th, 2018.
  • If you have purchased a certificate after December 1st, 2017, the Chrome browser will trust this certificate. You do not have to re-issue.