Kyo's coding life

.NET 5.0 上線啦! 這次帶來什麼樣的改變呢? .NET 5.0 的前一版是 .NET Core 3.1。 等等，為什麼不是 .NET 4.x 呢? 難道歪果仁也不喜歡 4 這個數字嗎? 當然不是，這是因為 4.x 很容易跟 .NET Framework 4.x 搞混，造成搜尋上的麻煩。 不過這只是其中一個理由，另一個理由是因為想把 Core 這個詞拿掉，原因是 .NET 5 是接下來的主要實作平台，其支援比 .NET Core 以及 .NET Framework 還要更多類型的應用程式或是更多的平台。 至於 ASP.NET Core 5 還是會有的! 是以 .NET 5 為基礎的核心實作。保留 Core 這個字 就是為了與 ASP.NET MVC 5 作區別 (他們總算了解之前查資料有多困難XD)，同樣的 Entity Framework Core 5.0 也會保留 Core 來跟 Entity Framework 5/6 作區別。 還有幾點是蠻重要的，.NET 5 做為未來的主要實作，但並不會取代 .NET Framework 4.x，.NET Framework 4.x 仍然會繼續支援。不過 Web Forms 技術將不會有轉移到 .NET 5 的計畫，取而代之的是有替代方案，例如 Blazor 或是 Razor page。 接下來讓我們期待 .NET 6.0 的登場吧! 畢竟這才是下一個 LTS 的版本阿!~

最近用 Java 8 在寫 Android 的 Side Project, 由於因為工作的關係比較熟悉 C#，寫一寫覺得很多地方很不習慣，除了 Json 要使用 Gson library 來做序列化以外，還有 C# 的 LINQ 在 Java 用發也差很多。 這裡特別紀錄一下 C# 中 LINQ 的 Select() var result = productList.Select(x = > x.name).ToList(); Console.WriteLine(result); 在 Java 中 有 Stream() 可以用。例如  String result = productList.stream() .map(p -> p.name) .collect(Collectors.toList()); System.out.println(result); 來完成，之後如果使用到更多的功能，再來補充吧~

之前有紀錄過開發的網站遇到 CSRF token 認證的問題，事實上解決的方法就是讓使用者盡量存取同一個 Pod 來避免從 A Pod 取得 token，但卻在 B Pod 驗證 token。在 K8s 上可以針對 ingress.yml 裡面去做設定  apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-ingress annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/affinity: " cookie " nginx.ingress.kubernetes.io/session-cookie-name: "hello-cookie" nginx.ingress.kubernetes.io/session-cookie-expires: "172800" nginx.ingress.kubernetes.io/session-cookie-max-age: "172800" nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/affinity-mode: persistent nginx.ingress.kubernetes.io/session-cookie-hash: sha1 spec: rules: - host: DOMAIN.NAME http: paths: - path: / backend: serviceName: hello-service servicePort: hello-port 這邊要強調的是 affinity : "cookie" 以及 affinity-mode: persistent。透過設定 persistent 的模式可以令 Po

最近開發網站碰到一個問題，有時候可以登入成功，有時候不行。但明明帳密都是 Google 記憶的，不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題，由於網站是透過 k8s 建立的，且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿，但登入是跟 B pod 登入，造成 token 無法驗證成功。 想證明這個問題，我們必須去紀錄 Log，由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦，因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現，CSRF 並不是丟出例外，而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果，並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行，這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN