I am .net Beginner,when the log-in request send from client to server in forms authentication
the server will sends authenticated cookies back to client after successfull log-in ,at every request cookies will sends to server.
so can we see this cookies on browser if yes then how?
Cookies can be read using this: http://www.w3schools.com/js/js_cookies.asp
I don't think the .NET framework cookies are exposed to the client, but could be wrong. Some cookies, if a setting is enabled on it (called HttpOnly) are server-only cookies and can't be read on the client. The name of the cookie is configurable in the web.config's element.
HTH.
Related
I'm a little confused about the cookie and I want to know can we use cookies somewhere other than the browser, like a mobile app or desktop app. Is the cookie dependent on the browser?
No, cookie is not dependent on browser.
Cookie is dependent on HTTP "User-Agent" -- the software/library client that is acting on behalf of a user, following HTTP protocol. Browser is just one type of it. Other types of "User-Agent" includes:
CLI software that can send HTTP request, such as curl or wget.
Library that can be imported in project and send HTTP request. Take Node.js project for example, they can be request or axios. All major programming language have its own HTTP client libraries.
Self-implemented HTTP client logic code.
more...
In a mobile app or desktop app, if HTTP is used for application, it is highly likely that cookie is used.
Any HTTP client can use cookies. A cookie is just a HTTP header sent by the server, with a value that is sent back to the server by the client in subsequent requests. Consult the documentation of your HTTP client to see if there is built-in support for remembering cookies.
Session Based Authentication
In the session based authentication, the server will create a session for the user after the user logs in. The session id is then stored on a cookie on the user’s browser. While the user stays logged in, the cookie would be sent along with every subsequent request. The server can then compare the session id stored on the cookie against the session information stored in the memory to verify user’s identity and sends response with the corresponding state!
Token Based Authentication
Many web applications use JSON Web Token (JWT) instead of sessions for authentication. In the token based application, the server creates JWT with a secret and sends the JWT to the client. The client stores the JWT (usually in local storage) and includes JWT in the header with every request. The server would then validate the JWT with every request from the client and sends response.
The biggest difference here is that the user’s state is not stored on the server, as the state is stored inside the token on the client side instead. Most of the modern web applications use JWT for authentication for reasons including scalability and mobile device authentication.
Scalability
Session based authentication: Because the sessions are stored in the server’s memory, scaling becomes an issue when there is a huge number of users using the system at once.
Token based authentication: There is no issue with scaling because token is stored on the client side.
Multiple Device
Session based authentication: Cookies normally work on a single domain or subdomains and they are normally disabled by browser if they work cross-domain (3rd party cookies). It poses issues when APIs are served from a different domain to mobile and web devices.
Token based authentication: There is no issue with cookies as the JWT is included in the request header.
Token Based Authentication: using JWT is the more recommended method in modern web apps. One drawback with JWT is that the size of JWT is much bigger comparing with the session id stored in cookie because JWT contains more user information. Care must be taken to ensure only the necessary information is included in JWT and sensitive information should be omitted to prevent XSS security attacks.
I would be grateful if someone would explain how servlets can tell that cookies have been disabled on the client's browser.
I understand that while creating a session in a servlet:
If cookies are enabled, the server will return the sessionID as a cookie.
If cookies are disabled, the sessionID will be written into the URL.
What I don't understand is how the server can tell that cookies have been disabled.
HTTP is a stateless protocol, there is no way (that I know of) the server can tell that the client has disabled cookies.
I expect that the server would not receive cookies in the request header but that could mean that no cookies have been set in the first place.
I have checked these answers:
Servlet HttpSession cookies disabled
Manage Session when broswer has disable cookies
They both explain how to enable URL-rewriting but they do not explain how the server knows cookies have been disabled on the client.
how servlets can tell that cookies have been disabled
They can't.
When the session is first created, the server sends the session ID both as a cookie and with URL rewriting. On the second request, if it receives the session cookie, then it stops rewriting URLs.
I'm sending username and password in the HTTP Body for authentication to each controller action in a Web API. I do the authentication in each controller using the username/password. It's using SSL.
Are there any security reasons why it's better to send the authentication credentials in the HTTP Header than in the HTTP body?
If I was using Basic Authentication I can see how having the credentials in the header are necessary as in this question but I'm not so I don't see the purpose. It seems just as secure in either as long as it's using SSL.
From an SSL perspective the security of the credentials in header (HTTP Basic auth) or body (e.g. form based logon) of an HTTP request is equal.
However if the client is a regular web browser you should consider the following:
Browsers cache the credentials used with HTTP basic authentication the users usually face the problem that for performing a log-out they would have to close their browser.
On the other side a form-based logon usually created a session cookie that is time restricted and can be deleted any time.
We are reaching an ASP.NET web application with WCF from Windows Phone. We use WIF on the server, the users of the application get the FedAuth cookie when they authenticate themselves with a WCF request. Afterwards we use the same cookie for every subsequent request to keep the user authenticated on the phone.
These cookies are HttpOnly, so they are not accessible directly, but that is not a problem, since we can share a CookieContainer object with every WCF service client.
However, we need to use a BackgroundTransferRequest to download a file from the server, where we also need to authenticate the user with the FedAuth cookie. But we can not access the cookie directly from the CoookieContainer, and BackgroundTransferRequest does not seem to support using a CookieContainer, only adding the cookies directly to its headers.
So my question is, how can I use BackgroundTransferRequest, if I have to send to the server the HttpOnly FedAuth cookie given by WIF? I would NOT want to switch off HttpOnly, if there is any other solution.
(I have seen that this specific question did not get any answers, which might mean it is not possible to directly associate a CookieContainer with a BackgroundTransferRequest.)
I have two virtual directories, one hosts an application the other hosts a web service layer running WCF with ASP.NET compatibility mode enabled.
The service project has an HTTP module that deals with authentication for incoming requests. The login service writes an authentication cookie to the client.
Subsequent requests are handled via AJAX (jQuery) to the services from the application project (another virtual directory on the same domain.)
Cookie domain is set correctly, the cookie path is "/", the cookie is set to HTTP ONLY so that scripts cannot interact with it.
My issue is the login service seems to be sending the SET-COOKIE header with the correct payload in the cookie, however the subsequent requests are not sending the cookie back to the server, in fact when inspecting the local store the cookie is not even there.
Potentially what could be my issues?
We tracked the issue down to Chrome. Apparently there was a prior bug that seems to be presenting itself again whereby expires cookies are not promoted to session and are instead discarded.