ASP.NET - регистрировать время начала / окончания сеанса пользователя для журнала аудита - Global.ASAX? - PullRequest
1 голос
/ 02 февраля 2010

Мое веб-приложение ASP.NET для внутренней сети использует проверку подлинности Windows, и я хотел бы записать следующую информацию:

1) идентификатор Windows
2) время начала сеанса
3) время остановки сеанса
4) URL-адрес для просмотра (необязательно)

У меня есть некоторые базовые настройки кода в методе "Session_Start" в Global.ASAX для регистрации времени начала сеанса (см. Ниже), ноэто так далекоЯ чувствую, что это примитивный подход, и есть «лучшие» способы сделать это.Итак, у меня действительно два вопроса:

1) Это правильный способ сделать это?Если нет, то какие еще есть варианты?

2) Если это правильный путь, мне просто нужно добавить какой-нибудь код в метод "Session_End", чтобы записать время, когда они выходят, и это полное решение?Всегда ли вызывается этот метод, когда они закрывают вкладку браузера, в которой открыт сайт, или они должны закрывать весь браузер (у меня нет функции выхода из системы)?Любой способ, которым пользователи могут пропустить этот метод завершения сеанса (или начать для этого случая)?

    Dim connsql As New System.Data.SqlClient.SqlConnection(ConfigurationManager.ConnectionStrings("MyConnectionstring").ConnectionString)
    Dim cmdsql As System.Data.SqlClient.SqlCommand = connsql.CreateCommand
    cmdsql.CommandText = "BeginUserSession"
    cmdsql.CommandType = Data.CommandType.StoredProcedure
    Try
        cmdsql.Parameters.Add("@windowsid", System.Data.SqlDbType.VarChar, 30, "windowsid")
        cmdsql.Parameters("@windowsid").Value = Session("UserInfo").identity.name
        If connsql.State <> System.Data.ConnectionState.Open Then connsql.Open()
        cmdsql.ExecuteNonQuery()
        connsql.Close()

    Catch ex As Exception

    Finally
        If connsql.State <> Data.ConnectionState.Closed Then connsql.Close()
    End Try
    'Stored Proc records start time

Ответы [ 3 ]

2 голосов
/ 02 февраля 2010

Session_End не является надежным.

Я хотел бы предложить, чтобы в Session_Start вы создавали запись, которая отмечала время создания сеанса, а в Session_End вы обновляли запись в момент ее окончания.

Чтобы обработать большинство сеансов, которые пассивно прерваны, используйте Application_BeginRequest, чтобы обновить запись, чтобы отметить, когда пользователь был «последний раз замечен».

Затем вам нужно будет определить способ маркировки сеансов, которые были пассивно прекращены. Это будет зависеть от сайта / приложения. Это может быть так же просто, как выбрать количество минут, которое должно пройти, прежде чем сессия будет считаться прекращенной - например, 10 минут.

Итак, у вас есть запрос:

SELECT Username,
       SessionStart,
       SessionEnd,
       LastSeenOn,
       DATEDIFF(mi, SessionStart, ISNULL(SessionEnd, LastSeenOn)) DurationMinutes
FROM   SessionAudit
WHERE  SessionEnd IS NOT NULL
OR     DATEDIFF(mi, LastSeenOn, getdate()) > 10

Что вернет ваш журнал аудита сеанса.

1 голос
/ 02 февраля 2010

Ваш подход может быть описан как простой, но это может быть совершенно нормально - все сводится к тому, каковы требования. Если вам нужно регистрировать полный набор ошибок и предупреждений приложения, посмотрите на реализацию чего-то вроде Log4Net. Иначе я бы не сказал, что с тобой что-то не так.

Сеансы заканчиваются, когда не было никакой активности пользователя в течение периода времени, указанного в значении времени ожидания, или когда вы явно вызываете Session.Abandon () в своем коде. Из-за природы HTTP без сохранения состояния невозможно определить, покинул ли пользователь ваш сайт, закрыл браузер или иным образом перестал взаимодействовать со своим сеансом.

0 голосов
/ 02 февраля 2010

Я не уверен, что вы можете точно поймать конец сессии, потому что

  1. Пользователь может закрыть свой браузер, и это не обязательно завершит сеанс.
  2. Затем они могут вернуться на ваш сайт и, таким образом, могут иметь несколько сеансов.

Вы можете попробовать изменить настройки в IIS, чтобы очень быстро завершить сеанс после бездействия, но это не очень хорошая идея.

Кроме того ... Если пользователи не все находятся во внутренней сети, вы не сможете контролировать, есть ли у них «Windows ID» или нет.

...