SignalR Güvenliğine Giriş (SignalR 1.x)Introduction to SignalR Security (SignalR 1.x)

, Patrick Fleti, Tom FitzMackenby Patrick Fletcher, Tom FitzMacken

Warning

Bu belge, SignalR 'nin en son sürümü için değildir.This documentation isn't for the latest version of SignalR. ASP.NET Core SignalR'ye göz atın.Take a look at ASP.NET Core SignalR.

Bu makalede, bir SignalR uygulaması geliştirirken göz önünde bulundurmanız gereken güvenlik sorunları açıklanmaktadır.This article describes the security issues you must consider when developing a SignalR application.

Genel bakışOverview

Bu belgede aşağıdaki bölümler yer alır:This document contains the following sections:

SignalR güvenlik kavramlarıSignalR Security Concepts

Kimlik doğrulaması ve yetkilendirmeAuthentication and authorization

SignalR, bir uygulamanın mevcut kimlik doğrulama yapısıyla tümleştirilecek şekilde tasarlanmıştır.SignalR is designed to be integrated into the existing authentication structure for an application. Kullanıcıların kimliğini doğrulamak için herhangi bir özellik sağlamaz.It does not provide any features for authenticating users. Bunun yerine, uygulamanızda normalde yaptığınız gibi kullanıcıların kimliğini doğrular ve ardından SignalR kodunuzda kimlik doğrulamanın sonuçlarıyla çalışırsınız.Instead, you authenticate users as you would normally in your application, and then work with the results of the authentication in your SignalR code. Örneğin, ASP.NET Forms kimlik doğrulaması ile kullanıcılarınızın kimliğini doğrulayabilir ve sonra merkezinizdeki bir yöntemi çağırmak için hangi kullanıcıların veya rollerin yetkilendirileceğini zorlayabilirsiniz.For example, you might authenticate your users with ASP.NET forms authentication, and then in your hub, enforce which users or roles are authorized to call a method. Hub 'ınızda, Kullanıcı adı gibi kimlik doğrulama bilgilerini veya bir kullanıcının bir role ait olup olmadığını istemciye geçirebilirsiniz.In your hub, you can also pass authentication information, such as user name or whether a user belongs to a role, to the client.

SignalR, hangi kullanıcıların bir hub veya metoda erişimi olduğunu belirtmek için Yetkilendir özniteliği sağlar.SignalR provides the Authorize attribute to specify which users have access to a hub or method. Yetkilendir özniteliğini bir hub 'da veya belirli yöntemlere uygularsınız.You apply the Authorize attribute to either a hub or particular methods in a hub. Yetkilendirme özniteliği olmadan, hub 'daki tüm ortak Yöntemler hub 'a bağlı bir istemci tarafından kullanılabilir.Without the Authorize attribute, all public methods on the hub are available to a client that is connected to the hub. Hub 'lar hakkında daha fazla bilgi için bkz. SignalR hub 'ları Için kimlik doğrulaması ve yetkilendirme.For more information about hubs, see Authentication and Authorization for SignalR Hubs.

Authorize özniteliği yalnızca Hub 'larla kullanılır.The Authorize attribute is used only with hubs. PersistentConnection kullanırken yetkilendirme kurallarını zorlamak için AuthorizeRequest metodunu geçersiz kılmanız gerekir.To enforce authorization rules when using a PersistentConnection you must override the AuthorizeRequest method. Kalıcı bağlantılar hakkında daha fazla bilgi için bkz. SignalR kalıcı bağlantıları Için kimlik doğrulaması ve yetkilendirme.For more information about persistent connections, see Authentication and Authorization for SignalR Persistent Connections.

Bağlantı belirteciConnection token

SignalR, gönderenin kimliğini doğrulayarak kötü amaçlı komutları yürütme riskini azaltır.SignalR mitigates the risk of executing malicious commands by validating the identity of the sender. Kimliği doğrulanmış kullanıcılar için bağlantı kimliği ve Kullanıcı adı içeren bir bağlantı belirteci, istemci ile sunucu arasında her istek için geçirilir.A connection token, containing the connection id and username for authenticated users, is passed between the client and server for each request. Bağlantı kimliği, yeni bir bağlantı oluşturulduğunda sunucu tarafından rastgele oluşturulan ve bağlantı süresince kalıcı olan benzersiz bir tanımlayıcıdır.The connection id is a unique identifier that is randomly generated by the server when a new connection is created, and is persisted for the duration of the connection. Kullanıcı adı, Web uygulaması için kimlik doğrulama mekanizması tarafından sağlanır.The username is provided by the authentication mechanism for the web application. Bağlantı belirteci, şifreleme ve dijital imza ile korunur.The connection token is protected with encryption and a digital signature.

Her istek için sunucu, isteğin belirtilen kullanıcıdan geldiğinden emin olmak için belirtecin içeriğini doğrular.For each request, the server validates the contents of the token to ensure that the request is coming from the specified user. Kullanıcı adı bağlantı kimliğine karşılık gelmelidir. SignalR hem bağlantı kimliğini hem de Kullanıcı adını doğrulayarak kötü niyetli bir kullanıcının başka bir kullanıcıyı kolayca taklit etmesini engeller.The username must correspond to the connection id. By validating both the connection id and the username, SignalR prevents a malicious user from easily impersonating another user. Sunucu bağlantı belirtecini doğrulayamazsa istek başarısız olur.If the server cannot validate the connection token, the request fails.

Bağlantı kimliği doğrulama işleminin bir parçası olduğundan, bir kullanıcının bağlantı kimliğini diğer kullanıcılara açığa çıkarmamalıdır veya bir tanımlama bilgisinde olduğu gibi istemci üzerindeki değeri depolamamalısınız.Because the connection id is part of the verification process, you should not reveal one user's connection id to other users or store the value on the client, such as in a cookie.

Yeniden bağlanıldığında grupları yeniden birleştirmeRejoining groups when reconnecting

Varsayılan olarak, SignalR uygulaması, bağlantı zaman aşımına uğramadan önce bir bağlantının düşürülme ve yeniden oluşturulması gibi geçici bir kesintiden yeniden bağlanıldığında bir kullanıcıyı uygun gruplara otomatik olarak yeniden atar. Yeniden bağlanıldığında, istemci bağlantı kimliği ve atanan grupları içeren bir grup belirteci geçirir.By default, the SignalR application will automatically re-assign a user to the appropriate groups when reconnecting from a temporary disruption, such as when a connection is dropped and re-established before the connection times out. When reconnecting, the client passes a group token that includes the connection id and the assigned groups. Grup belirteci dijital olarak imzalanır ve şifrelenir.The group token is digitally signed and encrypted. İstemci, bir yeniden bağlantıdan sonra aynı bağlantı kimliğini korur; Bu nedenle, yeniden bağlanan istemciden geçirilen bağlantı kimliğinin, istemci tarafından kullanılan bir önceki bağlantı kimliğiyle eşleşmesi gerekir.The client retains the same connection id after a reconnection; therefore, the connection id passed from the reconnected client must match the previous connection id used by the client. Bu doğrulama, kötü niyetli bir kullanıcının yeniden bağlanıldığında yetkisiz gruplara katılması için istekleri geçmesini engeller.This verification prevents a malicious user from passing requests to join unauthorized groups when reconnecting.

Ancak, Grup belirtecinin süre sonu olmadığı unutulmamalıdır.However, it is important to note, that the group token does not expire. Bir Kullanıcı geçmişte bir gruba aitdi, ancak bu gruptan yasaklanmış ise, bu kullanıcı yasaklanmış grubu içeren bir grup belirtecini taklit edebilir.If a user belonged to a group in the past, but was banned from that group, that user may be able to mimic a group token that includes the prohibited group. Hangi kullanıcıların hangi gruplara ait olduğunu güvenli bir şekilde yönetmeniz gerekiyorsa, bu verileri sunucuda (örneğin,) bir veritabanında depolamanız gerekir.If you need to securely manage which users belong to which groups, you need to store that data on the server, such as in a database. Ardından, uygulamanıza bir kullanıcının bir gruba ait olup olmadığını doğrulayan bir mantığı ekleyin.Then, add logic to your application that verifies on the server whether a user belongs to a group. Grup üyeliğini doğrulama örneği için bkz. gruplarla çalışma.For an example of verifying group membership, see Working with groups.

Grupları otomatik olarak yeniden birleştirme işlemi yalnızca geçici bir kesinti sonrasında bağlantı yeniden bağlandığında geçerlidir.Automatically rejoining groups only applies when a connection is reconnected after a temporary disruption. Kullanıcının bağlantısı kesilirse veya uygulama yeniden başlatıldıktan sonra, uygulamanız bu kullanıcının doğru gruplara nasıl ekleneceğini ele almalıdır.If a user disconnects by navigating away from the application or the application restarts, your application must handle how to add that user to the correct groups. Daha fazla bilgi için bkz. gruplarla çalışma.For more information, see Working with groups.

SignalR, siteler arası Istek sahteciliği nasıl engellerHow SignalR prevents Cross-Site Request Forgery

Siteler arası Istek forgery (CSRF), kötü niyetli bir sitenin kullanıcının şu anda oturum açtığı bir güvenlik açığı olan siteye istek gönderdiği bir saldırıya neden olur.Cross-Site Request Forgery (CSRF) is an attack where a malicious site sends a request to a vulnerable site where the user is currently logged in. SignalR, kötü amaçlı bir sitenin SignalR uygulamanız için geçerli bir istek oluşturması için son derece olası bir durum oluşturarak CSRF 'yi önler.SignalR prevents CSRF by making it extremely unlikely for a malicious site to create a valid request for your SignalR application.

CSRF saldırısı açıklamasıDescription of CSRF attack

CSRF saldırılarına bir örnek aşağıda verilmiştir:Here is an example of a CSRF attack:

  1. Kullanıcı, Forms kimlik doğrulaması kullanarak www.example.comoturum açar.A user logs into www.example.com, using forms authentication.

  2. Sunucu, kullanıcının kimliğini doğrular.The server authenticates the user. Sunucudan gelen yanıt bir kimlik doğrulama tanımlama bilgisi içerir.The response from the server includes an authentication cookie.

  3. Oturum açmadan, Kullanıcı kötü amaçlı bir Web sitesi ziyaret ettiğinde.Without logging out, the user visits a malicious web site. Bu kötü amaçlı site aşağıdaki HTML biçimini içerir:This malicious site contains the following HTML form:

    <h1>You Are a Winner!</h1>
    <form action="http://example.com/api/account" method="post">
        <input type="hidden" name="Transaction" value="withdraw" />
        <input type="hidden" name="Amount" value="1000000" />
        <input type="submit" value="Click Me"/>
    </form>
    

    Form eyleminin kötü amaçlı siteye değil, güvenlik açığı bulunan siteye gönderdiğine dikkat edin.Notice that the form action posts to the vulnerable site, not to the malicious site. Bu, CSRF 'nin "siteler arası" parçasıdır.This is the "cross-site" part of CSRF.

  4. Kullanıcı Gönder düğmesine tıklar.The user clicks the submit button. Tarayıcı, istekle kimlik doğrulama tanımlama bilgisini içerir.The browser includes the authentication cookie with the request.

  5. İstek, example.com sunucusunda kullanıcının kimlik doğrulama içeriğiyle çalışır ve kimliği doğrulanmış bir kullanıcının yapmasına izin verilen her şeyi yapabilir.The request runs on the example.com server with the user's authentication context, and can do anything that an authenticated user is allowed to do.

Bu örnek, kullanıcının form düğmesine tıklayabilmesine rağmen, kötü amaçlı sayfa yalnızca SignalR uygulamanıza yönelik bir AJAX isteği gönderen bir betiği kolayca çalıştırabilir.Although this example requires the user to click the form button, the malicious page could just as easily run a script that sends an AJAX request to your SignalR application. Üstelik, SSL kullanmak CSRF saldırılarına engel değildir çünkü kötü amaçlı site "https://" isteği gönderebilir.Moreover, using SSL does not prevent a CSRF attack, because the malicious site can send an "https://" request.

Genellikle, tarayıcılar tüm ilgili tanımlama bilgilerini hedef Web sitesine gönderdikleri için kimlik bilgilerini kullanan Web sitelerine karşı CSRF saldırıları mümkündür.Typically, CSRF attacks are possible against web sites that use cookies for authentication, because browsers send all relevant cookies to the destination web site. Ancak, CSRF saldırıları, tanımlama bilgilerini kötüye ile sınırlı değildir.However, CSRF attacks are not limited to exploiting cookies. Örneğin, temel ve Özet kimlik doğrulaması da savunmasız olacaktır.For example, Basic and Digest authentication are also vulnerable. Kullanıcı temel veya Özet kimlik doğrulamasıyla oturum açtıktan sonra, oturum sona erene kadar tarayıcı kimlik bilgilerini otomatik olarak gönderir.After a user logs in with Basic or Digest authentication, the browser automatically sends the credentials until the session ends.

SignalR tarafından alınan CSRF azaltmalarıCSRF mitigations taken by SignalR

SignalR, kötü amaçlı bir sitenin SignalR uygulamanıza geçerli istekler oluşturmasını engellemek için aşağıdaki adımları alır.SignalR takes the following steps to prevent a malicious site from creating valid requests to your SignalR application. Bu adımlar varsayılan olarak alınır ve kodunuzda herhangi bir işlem gerektirmez.These steps are taken by default and do not require any action in your code.

  • Etki alanları arası istekleri devre dışı bırakDisable cross domain requests
    Varsayılan olarak, kullanıcıların bir SignalR uygulamasında dış etki alanından bir SignalR uç noktası aramasını engellemek için, çapraz etki alanı istekleri bir SignalR uygulamasında devre dışıdır.By default, cross domain requests are disabled in a SignalR application to prevent users from calling a SignalR endpoint from an external domain. Dış etki alanından gelen her türlü istek otomatik olarak geçersiz kabul edilir ve engellenir.Any request that comes from an external domain is automatically considered invalid and is blocked. Bu varsayılan davranışı tutmanız önerilir; Aksi takdirde, kötü amaçlı bir site kullanıcıların sitenize komut göndermesini sağlayabilir.It is recommended that you keep this default behavior; otherwise, a malicious site could trick users into sending commands to your site. Çapraz etki alanı istekleri kullanmanız gerekiyorsa bkz. etki alanları arası bağlantı oluşturma .If you need to use cross domain requests, see How to establish a cross-domain connection .
  • Bağlantı belirtecini tanımlama bilgisine değil sorgu dizesinde geçirPass connection token in query string, not cookie
    SignalR bağlantı belirtecini tanımlama bilgisi olarak değil sorgu dizesi değeri olarak geçirir.SignalR passes the connection token as a query string value, instead of as a cookie. Bağlantı belirtecini bir tanımlama bilgisi olarak depolamadığınızda, kötü amaçlı kod ile karşılaşıldığında bağlantı belirteci yanlışlıkla tarayıcı tarafından iletilmez.By not storing the connection token as a cookie, the connection token is not inadvertently forwarded by the browser when malicious code is encountered. Ayrıca, bağlantı belirteci geçerli bağlantının ötesinde kalıcı değildir.Also, the connection token is not persisted beyond the current connection. Bu nedenle, kötü niyetli bir Kullanıcı başka bir kullanıcının kimlik doğrulama kimlik bilgileri altında istek yapamaz.Therefore, a malicious user cannot make a request under another user's authentication credentials.
  • Bağlantı belirtecini doğrulaVerify connection token
    Bağlantı belirteci bölümünde açıklandığı gibi, sunucu, kimliği doğrulanmış her kullanıcıyla ilişkili bağlantı kimliğini bilir.As described in the Connection token section, the server knows which connection id is associated with each authenticated user. Sunucu, Kullanıcı adıyla eşleşmeyen bir bağlantı kimliğinden gelen isteği işlemez.The server does not process any request from a connection id that does not match the user name. Kötü amaçlı Kullanıcı Kullanıcı adını ve geçerli rastgele oluşturulan bağlantı kimliğini bilmemiz gerektiğinden, kötü niyetli bir kullanıcının geçerli bir isteği tahmin etmesi olası değildir. Bağlantı sona erdikten hemen sonra bu bağlantı kimliği geçersiz hale gelir.It is unlikely a malicious user could guess a valid request because the malicious user would have to know the user name and the current randomly-generated connection id. That connection id becomes invalid as soon as the connection is ended. Anonim kullanıcıların herhangi bir hassas bilgilere erişimi olmamalıdır.Anonymous users should not have access to any sensitive information.

SignalR güvenlik önerileriSignalR Security Recommendations

Güvenli Yuva katmanları (SSL) protokolüSecure Socket Layers (SSL) protocol

SSL protokolü, istemci ve sunucu arasında veri aktarımını güvenli hale getirmek için şifrelemeyi kullanır.The SSL protocol uses encryption to secure the transport of data between a client and server. SignalR uygulamanız, istemci ve sunucu arasında hassas bilgiler gönderiyorsa, aktarım için SSL kullanın.If your SignalR application transmits sensitive information between the client and server, use SSL for the transport. SSL ayarlama hakkında daha fazla bilgi için bkz. IIS 7 ' de SSL ayarlama.For more information about setting up SSL, see How to set up SSL on IIS 7.

Grupları bir güvenlik mekanizması olarak kullanmayınDo not use groups as a security mechanism

Gruplar ilgili kullanıcıları toplamanın kolay bir yoludur, ancak gizli bilgilere erişimin sınırlandırılmasının güvenli bir mekanizması değildir.Groups are a convenient way of collecting related users, but they are not a secure mechanism for limiting access to sensitive information. Bu özellikle, kullanıcılar yeniden bağlanma sırasında gruplara otomatik olarak katılabileceği durumlarda geçerlidir.This is especially true when users can automatically rejoin groups during a reconnect. Bunun yerine, ayrıcalıklı kullanıcıları bir role eklemeyi ve bir hub yöntemine erişimi yalnızca o rolün üyelerine sınırlamayı göz önünde bulundurun.Instead, consider adding privileged users to a role and limiting access to a hub method to only members of that role. Bir role göre erişimi kısıtlama örneği için bkz. SignalR hub 'ları Için kimlik doğrulaması ve yetkilendirme.For an example of restricting access based on a role, see Authentication and Authorization for SignalR Hubs. Yeniden bağlanıldığında, gruplara kullanıcı erişimini denetleme örneği için bkz. gruplarla çalışma.For an example of checking user access to groups when reconnecting, see Working with groups.

İstemcilerden gelen girişi güvenle işlemeSafely handling input from clients

Diğer istemcilere yayın için tasarlanan istemcilerden gelen tüm girişler, kötü niyetli bir kullanıcının diğer kullanıcılara betik gönderemediğinden emin olmak için kodlanmalıdır.All input from clients that is intended for broadcast to other clients must be encoded to ensure that a malicious user does not send script to other users. SignalR uygulamanızda birçok farklı türde istemci olabileceğinden, iletileri sunucu yerine alıcı istemcilere kodlamak en iyisidir.It is best to encode messages on the receiving clients rather than the server, because your SignalR application may have many different types of clients. Bu nedenle, HTML kodlaması bir Web istemcisi için geçerlidir, ancak diğer istemci türlerine yönelik değildir.Therefore, HTML-encoding works for a web client, but not for other types of clients. Örneğin, bir sohbet iletisini görüntüleyen Web istemcisi yöntemi, html() işlevini çağırarak kullanıcı adını ve iletisini güvenle işleyebilir.For example, a web client method to display a chat message would safely handle the user name and message by calling the html() function.

chat.client.addMessageToPage = function (name, message) {
    // Html encode display name and message. 
    var encodedName = $('<div />').text(name).html();
    var encodedMsg = $('<div />').text(message).html();
    // Add the message to the page. 
    $('#discussion').append('<li><strong>' + encodedName
        + '</strong>:  ' + encodedMsg + '</li>');
};

Etkin bağlantıyla Kullanıcı durumunda değişiklik mutabık kılmaReconciling a change in user status with an active connection

Etkin bağlantı varken kullanıcının kimlik doğrulama durumu değişirse, "Kullanıcı kimliği etkin bir SignalR bağlantısı sırasında değiştiremeyecektir." şeklinde bir hata alır.If a user's authentication status changes while an active connection exists, the user will receive an error that states, "The user identity cannot change during an active SignalR connection." Bu durumda, bağlantı kimliği ve Kullanıcı adının koordine olduğundan emin olmak için uygulamanızın sunucuya yeniden bağlanması gerekir.In that case, your application should re-connect to the server to make sure the connection id and username are coordinated. Örneğin, uygulamanız etkin bir bağlantı varken kullanıcının oturumu açmasına izin veriyorsa, bağlantı için Kullanıcı adı artık sonraki istek için geçirilen adla eşleşmez.For example, if your application allows the user to log out while an active connection exists, the username for the connection will no longer match the name that is passed in for the next request. Kullanıcı oturumu kapatmadan önce bağlantıyı durdurup yeniden başlatmanız gerekir.You will want to stop the connection before the user logs out, and then restart it.

Ancak, çoğu uygulamanın bağlantıyı el ile durdurmanız ve yeniden başlatmanız gerektiğini unutmayın.However, it is important to note that most applications will not need to manually stop and start the connection. Uygulamanız, bir Web Forms uygulaması veya MVC uygulamasındaki varsayılan davranış gibi, Kullanıcı oturum kapatıldıktan sonra ayrı bir sayfaya yeniden yönlendirirse veya oturum kapatıldıktan sonra geçerli sayfayı yenileirse, etkin bağlantının bağlantısı otomatik olarak kesilir ve ek eylem gerektirir.If your application redirects users to a separate page after logging out, such as the default behavior in a Web Forms application or MVC application, or refreshes the current page after logging out, the active connection is automatically disconnected and does not require any additional action.

Aşağıdaki örnek, Kullanıcı durumu değiştiğinde bir bağlantının nasıl durdurulacağını ve başlatılacağını gösterir.The following example shows how to stop and start a connection when the user status has changed.

<script type="text/javascript">
    $(function () {
        var chat = $.connection.sampleHub;
        $.connection.hub.start().done(function () {
            $('#logoutbutton').click(function () {
                chat.connection.stop();
                $.ajax({
                    url: "Services/SampleWebService.svc/LogOut",
                    type: "POST"
                }).done(function () {
                    chat.connection.start();
                });
            });
        });
    });
</script>

Ya da sitenizin form kimlik doğrulaması ile kayan süre sonu kullanıyorsa ve kimlik doğrulama tanımlama bilgisinin geçerli tutulması için bir etkinlik yoksa kullanıcının kimlik doğrulaması durumu değişebilir.Or, the user's authentication status may change if your site uses sliding expiration with Forms Authentication, and there is no activity to keep the authentication cookie valid. Bu durumda, Kullanıcı oturumu kapatılır ve Kullanıcı adı bağlantı belirtecindeki Kullanıcı adıyla eşleşmez.In that case, the user will be logged out and the user name will no longer match the user name in the connection token. Kimlik doğrulama tanımlama bilgisinin geçerli tutulması için, Web sunucusunda düzenli aralıklarla bir kaynak isteyen bir betik ekleyerek bu sorunu çözebilirsiniz.You can fix this problem by adding some script that periodically requests a resource on the web server to keep the authentication cookie valid. Aşağıdaki örnek, her 30 dakikada bir kaynağın nasıl isteneceğini gösterir.The following example shows how to request a resource every 30 minutes.

$(function () {
    setInterval(function() {
        $.ajax({
            url: "Ping.aspx",
            cache: false
        });
    }, 1800000);
});

Otomatik olarak oluşturulan JavaScript proxy dosyalarıAutomatically generated JavaScript proxy files

Her bir kullanıcı için JavaScript ara sunucu dosyasına tüm Hub 'ları ve yöntemleri dahil etmek istemiyorsanız, dosyanın otomatik olarak oluşturulmasını devre dışı bırakabilirsiniz.If you do not want to include all of the hubs and methods in the JavaScript proxy file for each user, you can disable the automatic generation of the file. Birden çok hub ve yöntemlere sahipseniz ancak her kullanıcının tüm yöntemlerin farkında olmasını istemiyorsanız bu seçeneği belirleyebilirsiniz.You might choose this option if you have multiple hubs and methods, but do not want every user to be aware of all of the methods. Enablejavascriptproxy 'leri falseolarak ayarlayarak otomatik oluşturmayı devre dışı bırakabilirsiniz.You disable automatic generation by setting EnableJavaScriptProxies to false.

var hubConfiguration = new HubConfiguration();
hubConfiguration.EnableJavaScriptProxies = false;
RouteTable.Routes.MapHubs("/signalr", hubConfiguration);

JavaScript proxy dosyaları hakkında daha fazla bilgi için bkz. oluşturulan ara sunucu ve sizin için ne yapar.For more information about the JavaScript proxy files, see The generated proxy and what it does for you.

Özel DurumlarExceptions

Nesneler, istemcilere hassas bilgiler sergilebileceğinden, istemcilere özel durum nesneleri geçirmekten kaçınmalısınız.You should avoid passing exception objects to clients because the objects may expose sensitive information to the clients. Bunun yerine, ilgili hata iletisini görüntüleyen istemcisinde bir yöntemi çağırın.Instead, call a method on the client that displays the relevant error message.

public Task SampleMethod()
{
    try
    { 
        // code that can throw an exception
    }
    catch(Exception e)
    {
        // add code to log exception and take remedial steps

        return Clients.Caller.DisplayError("Sorry, the request could not be processed.");
    }
}