Situation: For a web application using SignalR, for sending messages from server(an Azure WebRole) to a browser, I need to access a browser cookie before sending each message to the browser. The cookie would contain some info to process/decode the message before sending it (I can't do this in java script, due to access complexities of decode algo).
The scenario would be to have the access to the cookie as soon as the message is ready in the server --> decode the message --> send the message.
Question : Does it make sense to ask the browser to give me the cookie before each message that I want to send to the browser? Or Does it ruins the whole idea of SignalR (being a always connected tcp)?
If it does make sense, then how would I go about this? How can I access cookie in the Hub?
If this would not be possible then I'd have to store the decode information in some persistent storage in the server.
P.S: I'm pretty new to SignalR, so pardon me if the question is too naive.
Cookies seem like a reasonable way to communicating immutable data from the client to the SignalR server. You can read a cookies from inside a Hub as follows:
public void MyHubMethod()
{
Cookie cookie = Context.Request.Cookies["cookieName"];
// ...
}
Just be aware that the request referenced by Context.Request will be very long running in the case of WebSockets, so don't expect to pick up any changes that may be made to cookie after you initiate the SignalR connection.
Related
I'm using Apache Shiro for my Rest service project and I have troubles getting it to work as intended.
For rest service,I use basic authentication and as first,when I send wrong username,It returns 401 as expected.
Then I send correct user name and password,It returns 200 as expected.
As 3th step,When I send again wrong username,It returns 200,should return 401.
I think after first successful login,It doesnt need any authentication process again.How can I force it to authenticate for every request?
I couldnt find any reason or any parameter I should add in my shiro.ini.
This is my shiro.ini:
What you are seeing may be the result of your client. Before a client will send credentials to a server typically has to ask for them (responding with a 401), the client will the add the auth header. A client can work around this using "preemptive" auth, which will send the Authorization header on the initial request.
Your server is likely also configured to use cookies, which the server will process first and then return a 200 (and the client would never send the new credentials).
If this is just a REST server/client setup, you could disable session creation, using the noSessionCreation filter.
https://shiro.apache.org/web.html#default_filters
If you are still stuck take a look at your HTTP logs and watch for the headers (specifically Authorization and an Cookie headers).
Hello everybody I'm trying to do a simple HTTP call to a Tomcat Server running on my server from my Android App. The server will then execute a certain command to my website. I created a button that when I click it runs the HTTP call from the App.
If I use the approach below, it opens the browser on my phone to run this HTTP. Is it possible to do something similar but not have my app open the browser???
Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://" + IP + ":8080/server/run.jsp"));
startActivity(browserIntent);
thank you so much in advance :D
Of course it starts your browser. Your code is explicitly asking Android to launch an app that can "view" the URL.
If you want your app to access the URL directly, use HttpURLConnection instead:
1.Obtain a new HttpURLConnection by calling URL.openConnection() and casting the result to HttpURLConnection.
2.Prepare the request. The primary property of a request is its URI. Request headers may also include metadata such as credentials, preferred content types, and session cookies.
3.Optionally upload a request body. Instances must be configured with setDoOutput(true) if they include a request body. Transmit data by writing to the stream returned by getOutputStream().
4.Read the response. Response headers typically include metadata such as the response body's content type and length, modified dates and session cookies. The response body may be read from the stream returned by getInputStream(). If the response has no body, that method returns an empty stream.
5.Disconnect. Once the response body has been read, the HttpURLConnection should be closed by calling disconnect(). Disconnecting releases the resources held by a connection so they may be closed or reused.
I'm attempting to have BizTalk broker the communication to a WCF service that maps some of its data within the response message's header and not the body portion. After researching, the solution was to write the header data to the OutboundCustomHeaders message context property and then the BizTalk WCF adapter will inject it into the outgoing message. This worked perfectly until I enabled message level security using a certificate. In this case, the header still gets included within the response message but AFTER the message is encrypted. This causes the receiving client to throw a MessageSecurityException with the message 'required message part was not encrypted."
Is there a way to configure BizTalk to write the OutboundCustomHeaders before encryption occurs or another way to inject my header in the response?
I'm not sure how much it helps or complicates the answer, but the receive location in BizTalk is using the ws2007HttpRelayBinding to create an Azure endpoint for the client connections.
The solution for this problem was found by creating a custom behavior that adds the required header to the channel protection requirements and attaching it to the ws2007HttpRelayBinding.
I used the following link as a reference to my solution: WCF custom messages security
Is there a protocol (or framework) that ensures that when a request fails, it fails on both the client side (iOS, Android, etc) and server side, and when it succeeds, successes on both sides?
The request might be completed on the server but because of dropped network connection, the client does not receive the response and thinks that the request failed.
The Post-Redirect-Get pattern can be adapted to this. The post part is used to submit the request, and the redirected get will be to a "results" page where the client can acquire the status (in progress, failure, success. etc).
Obviously, a client should not conclude from a network problem that the request failed. It should simply be prepared to wait and/or retry to obtain the status.
The interesting case is where the initial request submission is incomplete, i.e. nothing, not even the redirect comes back. This is where the adaptation comes in. The initial data submission should be after the server has generated a transaction identifier that the client can use as an alternative for status requests. (E.g., a form with a static field "Please save and use this tracking ID for status inquiries".)
If your question was whether this fallback can be automated at the protocol level, the answer unfortunately is no.
As per my understnding the difference between Response and Request is below
Request is - We request to server for like .aspx page
Response is - We get the .aspx page from server
So, I think, request is toward Server and response is what we got.
We have following terms
Request.QueryString
Request.RawUrl
Request.MapPath()
All these seems to go to server first and brings back the associated data. But the following term is contrary ?
Request.Cookies
Because the cookies creates at client side and value part is also fetched at client side using Response.Cookies
Your comments?
Query - 2 - Why it is useful to create/Access cookie using Request/Response.cookies? Because it can be created/fetched at client end in JavaScript.
Query 3 - Cookie resides at client end. Why do we send request to server ?
Query - 4 - Why do we write Response.Cookies? to go to server? Why? it creates at client end and accessed from client end. right? Why do we write Request.Cookies? Means fetching cookie information from server? Cookie is at client end. right?
"When a browser makes a request to the server, it sends the cookies for that server along with the request. In your ASP.NET applications, you can read the cookies using the HttpRequest object, which is available as the Request property of your Page class. The structure of the HttpRequest object is essentially the same as that of the HttpResponse object, so you can read cookies out of the HttpRequest object much the same way you wrote cookies into the HttpResponse object."
ASP.NET Cookies Overview
"Cookies are sent to the browser via the HttpResponse object that exposes a collection called Cookies. You can access the HttpResponse object as the Response property of your Page class"
Beginner's Guide to ASP.NET Cookies
Every time you send a Request to server, the cookies for that server are also sent.
Also, when the server sends you a Response it can include cookies for the next Request you send it to.
So Request.Cookies and Response.Cookies make perfect sense.
Both objects Request and Response "live" in the server. So Request holds the data sent by the User Agent (the Browser, like Chrome, IE, etc.). Examples of this data are, the POST and GET Variables, the User Agent, the language, IP Adress, and many more.
Response is the object that lets you send data to the User Agent (the browser), i.e. a Web Page, a stream of bytes (like a downloadable file), etc.
The cookies live in the client side, that's right, but is the browser that send this information, so this data comes in the Request object.
You receive the cookies via Request.Cookies, but you receive the cookies in the Server. If you are coding in C#, the code is in the Server point of view, so receive means, the server receives. If you want to access the cookies in the Client Side, you must use some client programming language like JavaScript.
I hope this helps.