‫۶ سال و ۳ ماه قبل، چهارشنبه ۹ خرداد ۱۳۹۷، ساعت ۱۴:۴۶
پیشنهاد من استفاده از امکانات Http Client جدید خود Angular و عدم استفاده از این کامپوننت هست (چون در پشت صحنه از Http Client استفاده نمی‌کند و مستقیما با مرورگر کار می‌کند): «یک نکته‌ی تکمیلی: به روز رسانی مثال مطلب جاری جهت گزارش درصد پیشرفت آپلود فایل‌ها توسط HTTP Client جدید Angular»
‫۶ سال و ۳ ماه قبل، چهارشنبه ۹ خرداد ۱۳۹۷، ساعت ۰۵:۴۵
اگر از MVC استفاده می‌کنید، روش آن‌را در قسمت تعریف مسیریابی مطلب فوق (آماده سازی برنامه‌ی ASP.NET جهت دریافت مجوزهای Let’s Encrypt) توضیح دادم و تست شده. اگر خیر، این تنظیمات را به فایل web.config اضافه کنید:
    <system.webServer>
        <staticContent>
            <clear/>
            <mimeMap fileExtension = ".*" mimeType="text/json" />
        </staticContent>
        <handlers>
            <clear />
            <add name="StaticFile" path="*" verb="*" type="" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" scriptProcessor="" resourceType="Either" requireAccess="Read" allowPathInfo="false" preCondition="" responseBufferLimit="4194304" />
        </handlers>
    </system.webServer>
‫۶ سال و ۳ ماه قبل، چهارشنبه ۹ خرداد ۱۳۹۷، ساعت ۰۲:۲۲
قبل از اجرای برنامه win-acme (با دسترسی admin) این آزمایش را انجام دهید:
- پوشه‌های تو در توی ذیل را در ریشه‌ی سایت به همراه فایل خالی emptyTextFile در آن ایجاد کنید:
/.well-known/acme-challenge/emptyTextFile
یک نکته: در ویندوز پوشه‌ای که با . شروع شود قابل ایجاد نیست؛ مگر اینکه یک . هم در انتهای نام آن قرار دهید که پس از enter، این . آخر حذف می‌شود.
- سپس مسیر http://mysite.com/.well-known/acme-challenge/emptyTextFile را در مرورگر باز کنید (این دقیقا کاری است که سرور let's encrypt انجام می‌دهد؛ البته فقط نام فایل آن متفاوت است). آیا این فایل خالی بدون پسوند، قابل دریافت و خوانده شدن هست؟
‫۶ سال و ۳ ماه قبل، سه‌شنبه ۸ خرداد ۱۳۹۷، ساعت ۱۹:۱۵
مجبور به حذف هدر «upgrade-insecure-requests» شدم؛ چون در قسمت اشتراک‌ها، تمام Redirectهای سایت را هم تبدیل به HTTPS می‌کرد (صرفنظر از اینکه آن سایت مقصد HTTPS را پشتیبانی می‌کرد یا خیر). همین مساله مرور سایت‌های HTTP را مشکل کرده بود.
‫۶ سال و ۳ ماه قبل، سه‌شنبه ۸ خرداد ۱۳۹۷، ساعت ۱۴:۵۷
- برای حالت Ajax ایی ارسال فایل‌ها، سمت سرور آن با مطلب فوق یکی هست. سمت کلاینت آن مانند قبل است: ارسال فایل و تصویر به همراه داده‌های دیگر از طریق jQuery Ajax      
‫۶ سال و ۳ ماه قبل، دوشنبه ۷ خرداد ۱۳۹۷، ساعت ۰۳:۱۹
بسته‌ی AspNetCoreCompat آن برای MVC 5x هست (البته پشتیبانی آنچنانی هم ندارد) و در کل خیر. معماری این‌ها یکی نیست. وابستگی‌های این‌ها یکی نیست. از دیدگاه مایکروسافت، MVC 5x در فاز نگهداری هست و نه توسعه‌ی اصلی. حتی قصد بازنشسته کردن Full .NET framework را با NET Core 3. دارند. قسمت‌های باقیمانده‌ی Full .NET framework که در NET Core. نیست، همان قسمت‌های دسکتاپ هستند (WPF و WinForms). این‌ها را هم قصد دارند در نگارش 3 به NET Core. اضافه کنند (به صورت غیرچندسکویی و فقط مختص ویندوز) که معنای غیرمستقیم آن هدایت توسعه دهندگان دات نت به صرفا NET Core. هست.
‫۶ سال و ۳ ماه قبل، یکشنبه ۶ خرداد ۱۳۹۷، ساعت ۱۴:۵۰
روشی بهتر برای مدیریت محتوای مخلوط (لینک به HTTP و HTTPS در یک صفحه) در مرورگرهای جدید

در مورد محتوای مخلوط و «اصلاح تمام آدرس‌هایی که پیشتر توسط برنامه تولید شده‌اند» در مطلب فوق نکته‌ای عنوان شده‌است. روش دیگر مدیریت آن که نیازی به اصلاح محتوای صفحات سایت را ندارد، استفاده از هدر امنیتی «Content-Security-Policy: upgrade-insecure-requests» است:
<system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security" value="max-age=16070400; includeSubDomains" />
        <add name="Content-Security-Policy" value="upgrade-insecure-requests;" />
      </customHeaders>
</httpProtocol>
کار این هدر ویژه ، ارتقاء خودکار لینک‌های درج شده‌ی در صفحات به نگارش‌های HTTPS آن‌ها است. برای مثال این تصویری است که پیش از اعمال این هدر جهت درخواست آدرس gravatar یک کاربر ارسال شده‌است و اخطار محتوای مخلوط را می‌دهد:


و این تصویری است که پس از اعمال هدر upgrade-insecure-requests قابل مشاهده‌است که دیگر اخطار محتوای مخلوط را به همراه ندارد: