Nik Faraday

1) Проверьте существование файла по указанному пути
2) Писать путь к файлу прямым текстом - плохая практика, такие данные нужно хранить где-то в константном виде, либо в конфигурации
3) Попробуйте записать в файл каждого юзера "По свойственно", т.е. каждое свойство/поле записать отдельно, это всё в цикле для каждого юзера
4) Запустите дебаг (Для 3го пункта), проверьте, что находится в файле после записи каждого юзера
5) Вообще, используйте базу данных)))

Вам нужно такую проверку

f ($(this).hasClass('active')) {
console.log('active')
};

делать после какого-то действия. jQuery не имеет возможности отслеживать изменения классов. Почитайте тут.

Сделал по другому - через ajax, что бы не использовать Url.Action. Ниже привёл часть скрипта:

buttons[i].onclick = () => {
        let buttonId = buttons[i].id.split('-')[1];
        let note = document.getElementById('note-' + buttonId).innerHTML;
        noteModal.innerHTML = note;

        $("#delete-note-btn").on('click', () => {
            let data = {
                NoteId: buttonId,
                ClientId: @Model.ClientId,
            };

            let jsonData = JSON.stringify(data);

            $.ajax({
                url: '@Url.Action("Delete", "Note")',
                method: 'post',
                data: jsonData,
                dataType: 'json',
                contentType: 'application/json; charset=utf-8',
                success: (response) => {
                    document.getElementById('modal-close-button').click();
                    setTimeout(() => {
                        location.reload();
                    }, 500);
                },
                error: (response) => {
                    // Autoredirect to error view
                },
            });
        });
    }

Разобрался

При создании объект ClaimPrincipal, который принимает коллекцию объектов ClaimIdentity, все клаймы будут доступны в HttpContext. Когда вам нужно получить текущего пользователя и его клаймы используя HttpContext(Accessor), свойство User.Claims имеет все клаймы из всех объектов ClaimIdentity, который были использованы во время авторизации, по этому необязательно париться по поводу того, какой из объектов Identity вытянуть, а можно сделать выборку из всех клаймов

Логирование используется для записи ошибок в како-то файл. Например, если вы, при чтении из БД получили Exception, тогда вы обращаетесь к логеру и вызываете метод .LogError куда передает ошибку в виде строки. Эта строка будет записана в файл, откуда вы потом сможете это прочитать.

Встроенный интерфейс ILogger<> подойдёт вам вполне. Для настройки места, куда будут сохраняться логи, читайте конфигурацию логера, как его правильно настроить

Да, логи пишутся вручную

Решение:

<style type="text/css">
    th, td {
        white-space: unset;
    }
</style>

Работает только в том случае, если в тексте есть пробелы, если пробелов нет, тогда текст так и будет вылазить за пределы монитора)

Ну, вы движетесь в верном направлении. Создать статический класс в котором будут записаны данные конфигурации и просто вызывать его в тех местах, где это нужно. Если значение нужно только для его получения, можете позначить его readonly (Как вы уже сделали) или public Get; private Set; для свойств.

Ещё как вариант, можете попробовать использовать статические файлы конфигурации

UPD: пример ниже приведён для MVC архитектуры. API выдаёт данные, а не страницы. HttpGet - это получение информации от сервера. HttpPost - отправка информации на сервер. Основная разница в тому, что Post запрос имеет тело запроса, в котором можно передавать сложные структуры. Get запрос может передавать данные через строку запроса

HttpGet и HttpPost это два стандартных типа запроса. Так же есть HttpPut, HttpDelete и некоторые другие, основные из каких я перечислил сначала.

Разница между HttpGet и HttpPost в очень простом виде:
HttpGet - выдача сервером какой-то информации клиенту. Для примера, сервер отдаёт какую-то информацию, допустим, имя и логин пользователя, который зашёл на сайт, для того, что бы отобразить её где-то на странице. Так же Get запрос может отдавать целые страницы в формате HTML или других форматах. По факту, большинство страниц, что вы видите в браузере, включая эту, была передана нам в браузер от сервера путём выполнения запроса. Такая информация передаётся как HttpGet.

HttpPost - это отправка данных на сервер. Любая. Когда вы регистрируетесь на сайте, ваши данные отправляются с использованием HttpPost запроса. Когда вы делаете изменения личной информации, обновлённые данные отправляются как HttpPost, хотя в REST API принято такой запрос помечать как HttpPut. Тут речь идёт об отправке сложных структур данных, возможно, фотографий, видео, аудио, информации о местонахождении, контактные данные. Т.е., другими словами, когда вы сервер уведомляете о какой-то новой информации.

Стоит отметить, что редирект через url является HttpGet запросом. Если вы просто делаете переадресацию на какую-то страницу и в url передаёте id клиента (Для примера), что бы на странице сведений вывести его данные (Опять же, чисто для примера), это НЕ HttpPost запрос, это просто редирект. Потому что вы не обновляете никакую информацию. Когда вы обращаетесь к серверу с просьбой отрисовать/отрендрить страницу и передаёте туда id клиента, сервер отдаёт ответ на HttpGet запрос, который имеет разметку самой страницы.

Иными словами, HttpGet запрос, это то, когда сервер должен отрисовать новую разметку или вернуть какие-то данные в некотором формате (В основном JSON для API). Может выполняться несколько запросов, если вы во время регистрации на сайте отправляете данные, делается сначала HttpPost запрос с отправкой ваших данных, а потом HttpGet, когда у вас рендрится новая страница, на которую вас перекинуло.

Так же есть HttpPut - аналогия HttpPost, разницы нет почти никакой. Обычно используется для обозначения запроса на обновление информации, т.к. HttpPost должен работать как запрос на создание. Тот же пример HttpDelete - когда нужно удалить информацию.