So a chat application with Websockets, user A can send any number of messages to the user B and user B can any number of messages to the user A. What if the chat application is built using HTTP protocol, would it work the same way but with more latency?
If you were to use the HTTP protocol instead of TCP or UDP it would look a little different. With the HTTP protocol you cannot simply send a packet from user A directly to user B, you would first need something like a RESTful web API to send the requests to. So it would look something like this:
user A sends POST request to the web API with the message as the request body
the web API receives and stores the message
user B sends a GET request to the web API requesting to see the stored message
the web API receives the get request and returns the message to user B
this might have a little more latency than using other protocols. You can also add authentication in your API to verify the users before accepting or returning any messages.
Related
I'm learning about OpenID connect and OAuth2.0 and i think there is something missing, what the client will do after receiving the ID token from the authorization server?
Ok it now has a JWT that contains information about the user, but when the user wants to send a request to the client to do whatever he wants to do, he should attach a token with his request, right? so, when the client will generate this token? as far as i know, if a server uses HTTP as its protocol, it can't send data to the user if the user didn't issue a request, so it shouldn't be able to send that token without a request from the user.
Did i miss something?
I tried to search about this stuff, and I didn't find anything useful.
Ok it now has a JWT that contains information about the user, but when
the user wants to send a request to the client to do whatever he wants
to do, he should attach a token with his request, right?
Should say "but when the client wants to send a request to the server ..."
if a server uses HTTP as its protocol, it can't send data to the user
if the user didn't issue a request, so it shouldn't be able to send
that token without a request from the user.
The token will have been provided to the client during sign-on process.
To summarise the process:
Client enters credentials (e.g. username and password) and sends those to a login endpoint.
The login server will generate a JWT and return to client.
Client receives a JWT and caches it locally at the client end ready to be sent to the server on subsequent requests.
On all subsequent requests to the server the client will attach the cached JWT in the authorization headers of the http request.
The server will validate the token to ensure client is authenticated.
I want to create some sort of proxy between my android/web application plus the firebase backend so that, every time an android/web application sends a request, I catch that request and create a log with it in the proxy.
Then, the proxy must redirect that request to Firebase, receive the response from the request and send it to the application.
It is possible to do something like this? It is possible to redirect requests from applications to an external system before the request reaches Firebase?
Example:
Mobile Application <---> Proxy (log) <---> Firebase
I've seen that this can be achieved by creating a cloud function that receives the request from the application and redirects it (through an HTTP request) to the external system.
Then the external system sends the HTTP request (also through an HTTP request) to Firebase, receives the response, and sends it to the application.
It this a good solution? Or is there and easier solution?
I want to create the web application (SPA with angular) with token based authentication.
It is required create the access token with short live-time, perhaps 1 hour expiration.
I want to use the SignalR for real-time communication and I have tried send the access token via query string after starting signalr connection.
If is access token expired I create the http request for refresh it and recieved it to the javascript.
How can I send the new access token if is signalr connection is running?
Is possible change the token or is necessary close the connection and create new again?
It depends on the transport technology that is used. In case of websockets you have to stop the connection, set the query-string and restart the connection. With other technologies you can directly change the query-string. You can check $.connection.hub.transport.name to learn what transport method is being used.
I'm tasked with creating a service-oriented ecosystem for a client. The whole thing is going to be REST based and built in ASP.NET, but my question is technology-agnostic. We want to have a centralized authentication service that issues JWT tokens and claims that are trusted by the other services in the environment.
My issue is this - what's the first thing that a web client (browser) requests? All of the diagrams I've seen (I'll try to add a couple of example links) make it seems as if the client needs to be self-aware and realize that they're going to need a token before they make the first request to the functional REST service, which seems, well, janky to me.
The way I want it to work is that they just attempt to access the secured resource, but there's no auth token with the request my REST service challenge them for user/password, but then delegate the authentication to my auth service. So:
Browser requests restricted resource on REST service
REST service returns 401
Browser gathers credentials, sends to same web service
REST service connects to the authentication service, passing along the Auth header from the client's request
Auth service creates the JWT token and returns it to the REST service
REST service validates the JWT and replaces the Auth header with the JWT token
JWT token is persisted for subsequent requests, up to expy setting
...am I completely off about this? Does the web client need to know that there's a separate auth service involved and make one request there to get their JWT, and then a second request for the REST resource passing the JWT? That seems clunky to me, I hope that's not the idea.
Also, another n00b question - is the JWT token automagically kept by the web clients and re-sent with every request so I don't have to go through the auth service step each time? Is that what the expiration setting is for?
TIA.
See figure 1 here for an example of what I mean: http://msdn.microsoft.com/en-us/library/hh446531.aspx
Starting with your last question will make the rest of the answers clearer:
"...is the JWT token automagically kept by the web clients and re-sent with every request.." - The idea is to issue JWT once, send it to the client so client can save it and send it on each subsequent request. This way your front-end app will send username and password just once and then use JWT for authentication. You will have to store the JWT using browser storage (local or session) or cookies (common fallback for older browsers).
"...Does the web client need to know that there's a separate auth service involved..." - You will need to send the username and password to a service in order to have the JWT issued. You could implement it with just one request, but you need to send credentials to the service (provided by the user), receive JWT as part of response and store it (as above). It might be easier to do it on a separate request, depending on requirements and implementation.
I would like to know if there is an API which can receive push notifications for an email client.
Use Case: I would like the server to send my web service notifications on new email. I would not like to poll the server. I would like the server to send notification (PUSH) to the web application.
Also, what are the (if any) mail servers that support this kind of API?
Check out Cloudmailin which is a SAS that will do REST post back to your server