chrome 部署自動清除cookie 設定

透過chrome登入某些網站後，都會產生cookie，下次在登入時，就可以不用輸入帳密就登入了，像是spotify，teams等等的網站。

但有時後卻希望網頁關閉，這些cookie就清除掉，避免下一次登入又自動使用上一次的帳密登入。

chrome的設定裡有一個清除cookie的功能，但這會清除所有的cookie，沒辦法只清除特定網站的cookie，也不太方便。

如果希望某網站的cookie在網頁關閉後清除，其實有另一個地方可以設定。

一律在視窗關閉時清除 Cookie，這邊就可以把要自動清除cookie的網站加入就行了。

如果公司裡電腦很多台，要一台一台設定太麻煩了。

可以去下載chrome的adm檔(https://enterprise.google.com/chrome/chrome-browser/#download)

。

然後在群組原則管理工具中，新建一個gpo，先把chrome的adm新增到系統管理範本中，就可以看到裡面有google chrome的設定可以做部署。

在"將來自相符網址的cookie限制在目前的工作階段中"，把網址加入，之後使用者開啟這些網站，只要關掉chrome，cookie就會刪除，不保留。

To enhance and translate the content provided:

When logging into certain websites using Chrome, cookies are generated. These cookies allow subsequent logins without the need to enter the username and password again. Websites like Spotify, Teams, and others utilize this feature.

However, there are times when you may prefer to clear these cookies upon closing the webpages to avoid automatically using the previous login credentials during the next login.

Chrome's settings include a cookie-clearing function, but it clears all cookies and lacks the ability to selectively remove cookies from specific websites, which can be inconvenient.

If you wish to automatically clear cookies from a particular website upon closing the webpage, there is another way to configure this setting. You can choose to "Clear cookies and site data when you quit Chrome" by adding the desired websites to this option.

If there are multiple computers within your company, individually configuring the settings on each one can be tedious. You can download the Chrome ADM template from (https://enterprise.google.com/chrome/chrome-browser/#download).

Next, in the Group Policy Management tool, create a new GPO and add the Chrome ADM file to the Administrative Templates section. This will allow you to see the available Google Chrome settings for deployment.

Under the "Limit cookies from sites that match the following URL" option, add the website URLs. Once users open these websites, closing Chrome will automatically delete the cookies, ensuring they are not retained.

安裝ocs agent 出現錯誤 api-ms-win-crt-heap-l1-1-0.dll

 64位系統安裝請安裝：

Visual C++ Redistributable for Visual Studio 2015 (Windows 64-bit)

32位系統安裝請安裝：

Visual C++ Redistributable for Visual Studio 2015 (Windows 32-bit)

When installing the OCS agent, an error occurs: api-ms-win-crt-heap-l1-1-0.dll.

For 64-bit systems, please install:

Visual C++ Redistributable for Visual Studio 2015 (Windows 64-bit).

For 32-bit systems, please install:

Visual C++ Redistributable for Visual Studio 2015 (Windows 32-bit).

shioaji 組合單多次IOC大失誤

在shioaji下單的模式中，只有ROD 、FOK、IOC三種。

如果要下組合單，需要使用到多次IOC的話，但shioaji系統內無多次IOC可以直接使用，就必須用迴圈讓系統一直重覆執行IOC，但在執行前，必須先確認庫存是否已有單，有單就表示成交，就不能在繼續跑，不然就可能會一直下單下到滿為止。

所以在下IOC前，有先做檢查庫存，但檢查庫存的功能卻失效，一直下單，還好戶頭裡錢不多，下了10口就停了。

檢查程式才發現，原來是檢查庫存的變數在更外圈的程式中，所以第一次成交後，下單前檢查庫存的變數未更新，還保持是0，所以就繼續下IOC，繼續成交。

在測試多次IOC真的要小心，錢不能放太多，以免不小心就直接被下滿。

透過瀏覽器(web)使用Teams 會議 聲音非常小

 使用teams程式開會音量正常，但用瀏覽器開會時，聲音超級小，喇叭已調到最大聲了，還是沒用，其他程式的聲音都正常，唯讀teams有問題。

原來是win10的音效設定，可以針對各別程式設定音量，所以要去音效裡做調整。

When using the Teams application, the volume during meetings is normal. However, when using a web browser for meetings, the sound is extremely low. Even with the speakers set to maximum volume, the issue persists. The sound in other applications is normal, indicating that Teams is the only program with this problem.

The cause of the issue lies in the audio settings of Windows 10, which allows for individual volume adjustments for each program. Therefore, it is necessary to adjust the settings in the sound configuration panel.

FORTIGATE自動備份設定檔

Fortigate現在的系統已有自動化備份的功能了，設定方式就直接看下圖說明

先到自動化動作

新增一個觸發器

在觸發器的項目中，找到預約行程

設定要執行的時間，就完成觸發器的新增。

再去新增一個動作

選擇cli腳本

加入腳本內容，下面四個選項要自行調整

1-輸入ftp的存放位置，並自行取一個備份檔的名稱

2-ftp server的ip

3-ftp登入帳號

4-ftp登入密碼

動作完成後，最後就是建立一個自動化動作，把剛剛的觸發器跟動作加進來，就完成了。

Fortigate now has a built-in feature for automated backups. The configuration process is in the following steps:

Go to "Automation Actions."

Add a new trigger.

In the trigger options, select "Scheduled Task."

Set the desired execution time for the trigger, and the addition of the trigger is complete.

Add a new action.

Choose "CLI Script" as the action type.

Include the script content, adjusting the following four options:

Enter the FTP storage location and assign a backup file name.

Specify the FTP server's IP address.

Provide the FTP login username.

Enter the FTP login password.

Once the action is configured, proceed to create an automation action by adding the previously created trigger and action.

The setup process is now complete.

Please refer to the accompanying image for detailed instructions.

python 書 網站 推薦

 這篇就是以一個完全不懂程式的人， 分享學習Python的一些書或網站，主要就是以能讓初學者比較好懂的內容為主。

書的話，下面這兩本就是自己有看完覺得還不錯的，大概就是要範例多一點，但不要太長，而且對程式的說明要多詳細一點:

1-Python零基礎入門班(第三版)

2-跟著阿才學Python

網站的話，就推薦YOUTUBE上的彭彭，內容豐富，講的也很仔細，難怪網路上也一堆人在推薦。

https://www.youtube.com/watch?v=wqRlKVRUV_k&list=PL-g0fdC5RMboYEyt6QS2iLb_1m7QcgfHk&index=1

網域DC時間錯誤造成client電腦時間也錯了

 一台虛擬機DC的時間被設定成與底層hyperv系統同步，結果與正確的時間差了一分多鐘。

PDC的時間是正確的，所以並不是所有client電腦的時間都錯了，就看是抓到哪台DC做時間同步。

時間錯誤的DC一開始就直接用NTPCLOCK這個小工具調整成對的時間，但沒多久又變回錯的時間，在該伺服器執行"w32tm /query /configuration"，有看到有一區"VMICTimeProvider"的設定，enable=1，這就是設定成與底層hyperv系統同步的地方。

直接找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider ，把enable改成0就好，不用重開機，然後在用NTPCLOCK調成正確時間就行了。

Client端如果不想等重開機做時間同步的話，可以下指令直接強制同步。

要用系統管理員執行cmd，然後輸入 w32tm /resync就可以開始同步了，時間不會馬上就變正確的，而且會慢慢的縮小與正確時間的差距，所以要等一下。

可以開啟client的時鐘，如果是client的時間是比較慢，就會發現秒數有時後會跳的比較快，然後慢慢跟上正確的時間。

Domain Controller Time Error Causing Incorrect Client Computer Time

The time of a virtual machine Domain Controller (DC) was initially set to synchronize with the underlying Hyper-V system, but it ended up being more than a minute off from the correct time.

The time displayed on PDC files was accurate, indicating that not all client computers had incorrect time settings. It depended on which DC the clients synchronized their time with.

Initially, the DC with the time error was adjusted using a small utility called NTPCLOCK to set the correct time. However, after a short while, it reverted back to the incorrect time. When running the command "w32tm /query /configuration" on the server, the configuration showed a section called "VMICTimeProvider" with enable=1, indicating synchronization with the underlying Hyper-V system.

To resolve this, the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider was located, and the "enable" value was changed to 0. There was no need to restart the server. Afterward, the correct time could be set using NTPCLOCK.

For client computers that didn't want to wait for a reboot to synchronize their time, a command could be executed to force synchronization. By running cmd as an administrator and entering "w32tm /resync," the synchronization process would begin. The time wouldn't immediately become correct but would gradually narrow the gap with the accurate time. Patience was required.

Observing the client's clock, if the client's time was slower, one would notice that the seconds occasionally jumped ahead and slowly caught up with the correct time.

弱點掃描 Vulnerable' cipher suites 處理

在用弱點掃描軟體做伺服器弱點檢查時，有些主機有下列這個弱點被掃出: 

Vulnerable' cipher suites accepted by this service via the TLSv1.0 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

'Vulnerable' cipher suites accepted by this service via the TLSv1.1 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

'Vulnerable' cipher suites accepted by this service via the TLSv1.2 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

就是有3個TLS的連線協定用了不安全的密碼套件TLS_RSA_WITH_3DES_EDE_CBC_SHA。

網路上比較多的解決方法是用IISCrypto這套軟體，免安裝，直接在伺服器上執行，它會列出很多種連線協定跟密碼套件，把你不要的取消勾選按下套用，重開機，就好了。

也有人說要去改機碼，只是比較麻煩，用IISCrypto比較快。

所以我就在查了一下IISCrypto跟改機碼差在哪，結果是一樣的，IISCrypto背後的方式也是改機碼。

所以就決定自己用改機碼的方式在處理:

因為三個連線協定都是用同一個有問題的密碼套件，因此直接先停用這個密碼套件看看。

原本在Chiphers底下是沒有Triple DES 168，就直接新增，加入這段機碼

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]

"Enabled"=dword:00000000

好了之後不用重開，直接在掃一次，就沒有這三個弱點出現了。

When conducting a vulnerability scan to check for server weaknesses, some hosts may exhibit the following vulnerability:

Vulnerable cipher suites accepted by this service via the TLSv1.0 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

Vulnerable cipher suites accepted by this service via the TLSv1.1 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

Vulnerable cipher suites accepted by this service via the TLSv1.2 protocol:

TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)

These vulnerabilities involve the usage of insecure cipher suites, specifically TLS_RSA_WITH_3DES_EDE_CBC_SHA, across all three TLS connection protocols.

One commonly suggested solution found online is to use a software called IISCrypto. It can be executed directly on the server without installation. IISCrypto provides a comprehensive list of connection protocols and cipher suites, allowing users to deselect undesired options, apply the changes, and then reboot the server.

Another approach involves modifying the registry, although this method is considered more cumbersome compared to using IISCrypto, which is faster.

After researching the differences between IISCrypto and registry modification, I discovered that they achieve the same result, as IISCrypto utilizes changes to the registry behind the scenes.

Therefore, I decided to handle the issue by modifying the registry myself:

Since all three connection protocols employ the same problematic cipher suite, the first step was to disable this specific cipher suite.

Initially, the "Triple DES 168" option was not present under the Chiphers section, so I added it directly by inserting the following registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]

"Enabled"=dword:00000000

After applying this modification, there was no need to restart the system. Running another scan revealed the absence of the aforementioned three vulnerabilities.

永豐 shioaji api 登入後只有證券帳號 沒有期權帳號

跟期貨營業員確認已申請好了shioaji的api後，在python下指令要列出帳號清單，發現都只有證券帳號，沒有期權帳號，有點怪。

後來上了永豐api官方的telegram去發問，才知道原來當初在申請api key的時後，因為只有證券戶，期貨戶還沒開好，所以申請api key的過程，只有證券戶可以勾選，所以用那組api key登入時就只有證券帳號可以用。

重新在申請一次api key，勾選期權選項後，登入測試就有列出期權帳戶了。

Greenbone Security Assistant 掃描錯誤 : Interrupted at 0 %

之前建了一台 Greenbone Security Assistant做弱點掃描，都很正常，掃完就沒管它，過了快一個月，要在掃一些之前掃過的主機時，工作開始後沒多久就會出現"Interrupted at 0 %"的錯誤，重試幾次都一樣，也沒找到什麼資訊，直接重開機吧。

然後就好了!!!!

Greenbone Security Assistant Scanning Error: Interrupted at 0%

Previously, I set up a Greenbone Security Assistant for vulnerability scanning, and everything was working fine. Once the scans were completed, I didn't pay much attention to it. After almost a month, when I tried to scan some hosts that were previously scanned, I encountered an error shortly after starting the scan, stating "Interrupted at 0%". I retried several times, but the error persisted, and I couldn't find any helpful information. Eventually, I decided to restart the machine.

And guess what? The issue was resolved after the restart!