How can I access the client URL in a Web Worker? I can access the client and URL in a Service Worker with the Clients API, but I have not found a way to do that with Web Workers.
I need to know what page the user is viewing to conditionally change the data posted from a Web Worker. For separation of concerns, I can't handle anything on the client itself.
You can't. The Worker knows its own location, accessible through self.location, but it doesn't have access to the one of its creator.
The only way is to have your main thread to pass that info to your Worker, e.g through postMessage.
Related
In my service worker, I have to generate some text. The problem is updating service worker language when app language changes. The only idea I have is having a service worker for every language, which is not a scalable solution.
The client app that is registering the service worker is a Spring app, in which I get locale using pageContext.response.locale.language (not compatible with JS).
Are there any other approaches to this problem?
I'm not completely sure what you're trying to do, but I guess you need to communicate the change of the language setting to the Service Worker. You can communicate that from the application's regular JS code via the postMessage API. Using postMessage, you can send arbitrary messages from the page to the SW and vice-versa.
Then it's a matter of what your SW does after receiving the message. Maybe it then generates different text based on the chosen language. This way you only have one SW that knows how to generate different language versions of the text and it does so depending on the lang setting of the user.
When creating a react app, service worker is invoked by default. Why service worker is used? What is the reason for default invoking?
You may not need a service worker for your application. If you are creating a project with create-react-app it is invoked by default
Service workers are well explained in this article. To Summarise from it
A service worker is a script that your browser runs in the
background, separate from a web page, opening the door to features
that don't need a web page or user interaction. Today, they already
include features like push notifications and background sync and have
ability to intercept and handle network requests, including
programmatically managing a cache of responses.
In the future, service workers might support other things like
periodic sync or geofencing.
According to this PR to create-react-app
Service workers are introduced with create-react-app via
SWPrecacheWebpackPlugin.
Using a server worker with a cache-first strategy offers performance
advantages, since the network is no longer a bottleneck for fulfilling
navigation requests. It does mean, however, that developers (and
users) will only see deployed updates on the "N+1"
visit to a page, since previously cached resources are updated in the
background.
The call to register service worker is enabled by default in new apps but you can always remove it and then you’re back to regular behaviour.
In simple and plain words, it’s a script that browser runs in the background and has whatsoever no relation with web pages or the DOM, and provide out of the box features. It also helps you cache your assets and other files so that when the user is offline or on slow network.
Some of these features are proxying network requests, push notifications and background sync. Service workers ensure that the user has a rich offline experience.
You can think of the service worker as someone who sits between the client and server and all the requests that are made to the server pass through the service worker. Basically, a middle man. Since all the request pass through the service worker, it is capable to intercept these requests on the fly.
I'd like to add 2 important considerations about Service Workers to take into account:
Service Workers require HTTPS. But to enable local testing, this restriction doesn't apply to localhost. This is for security reasons as a Service Worker acts like a man in the middle between the web application and the server.
With Create React App Service Worker is only enabled in the production environment, for example when running npm run build.
Service Worker is here to help developing a Progressive Web App. A good resource about it in the context of Create React App can be found in their website here.
Case scenario:
I have few 2k concurrent users access to the website with various devices but using their browsers. Once one of them create new topic, all others currently connected should receive a notification (basically I simple update little icon number in app upper right corner).
One way to accomplish this is to have web app keep requesting updates via ajax calls but that overload my slow server with numerous requests.
I use azure to host my web app (written in PHP). There are some services included in my hosting package such as Event Hub, Service Bus etc. What service could I use in order to have my backed talk to a "service" whenever there is a new post, and than to have that "service" talk to my clients (their browsers) and informing them about new notification or any type of data updates?
You're probably looking for websockets. A websocket sets up a connection between the page in the client's browser and your webserver. Through this connection you can push new topics to all connected clients.
It is advisable to decouple the websocket sending process from the request handling of the topic creation. For this you need a background worker which sends websocket notifications when triggered from a processing event.
You can implement this in PHP using ratchet.
I wish to build a pure front-end app with JavaScript running on client-side, i.e. browser. My app is supposed to make requests to 3rd part services, which require some sort of authentication method.
Backend frameworks provide config files for this sort of thing, but since JS code is all interpreted on the client machine, the config files cannot be part of the bundle.
Is there any way of securely storing the service API keys, credentials and such within the client or do I need a backend solution for this also?
Search for most popular frameworks (Angular and React) for config files resulted only in storing environment-specific URLs. I'm starting to think that I've hit a dead-end and this simply can't be done.
Depends... You don't want the user to be able to sniff out any secrets you have to send to the third party, but in the case of an Implicit Grant with OAuth2, you can actually initiate and complete it in the browser.
You'll redirect to the 3rd party for login/authentication, then the user will be sent back to you with an access token good for a period of time.
That token is actually sent in a URL fragment, per the spec, so it's being sent to the browser and NOT your server. If you want to get the access token to a server, you'd need front-end code to parse the URL fragment and send its contents.
If the API will allow you to connect from the browser, you could keep everything in the browser and not need a backend server to handle credentials. But not every API will allow purely front-end authentication and API calls.
So, it depends...
Can you store service api creds in the client cache, or in cookies etc? Yes. Will it be secure to send them over the wire and store in the browser? No.
If keeping credentials secure is part of the requirements, I would do the work to authenticate on the backend or use a third party service that does this for you.
I've been looking around for an answer to this question, but it looks like that nobody does this. Imagine you are designing a javascript REST client, and you want to create a login page. Surely, after the login you will be authenticated.
So the following requests to the REST API will depend on your current user id, which should be stored on the client side following the RESTful way.
My question is how to store this "session" information using Javascript. I've looked into cookies, but it seems to me too much plain text for one to trust. Also using cookies one could store there an session id that maps to the user information on the server, but this violates the Stateless concept from REST.
Which the best approach to solve this problem?
We are also building similar kind of architecture where RESTful API will be accessed by a javascript client.
We will authenticate client with client credentials and generate an authentication token and that will be sent to client. Client will store it in cookie or in local data store. Further requests to API from this client will be sent using HTTP authorization header and including that token in the header. We will authorize the request at API end for the given token and request will be served once it is authenticated.
Until n unless you don't access cookie information on server side I don't think this will violate stateless principle of REST as we are not maintaining any state of the client on server (we are but not binding it to any server). Regarding the authentication process using token, I don't think we are binding the server and client here, because we have multiple servers and using load balancer and still this request may be served by any server (similar to Google api).
Note: We are doing this using HTTPS protocol so we are sure that all this communication is secured.