As part of a project I am working on, I have integrated an iframe from a 3rd party service. This iframe sends a message when its task is completed, but the message has no data in it, just a success message. In the console, the iframe is constantly logging its redux state which has a lot of good information that I want. I can also see this information using redux developer tools. Is there any way to access the redux state of this third party app from within my react/redux app? I can't find it stored anywhere on the window or anything.
No, you cannot. It would be a security concern, otherwise.
The iframe would need some worker that would actively send information to your app, that would accept that work, so both instances can communicate with each other.
Related
The problem
I am following a Vue.js 3 tutorial on youtube and I tried to implement the app shown in this video.
Then I started improving it a bit at a time. You can view my project here.
One of the main features I am trying to add is a Hall of Fame component in which you can view the best ten scores of anyone who plays. You can submit your score just after finishing the game. I decided to use Firestore to hold the data.
However, suppose I build the app for production and host it in a server. Then, I can download the whole project on my laptop, change a little bit the logic, and then play it locally on my computer. That way, I can send any type of data to my firestore database (because my credentials are injected in the javascript by Vue). I can then just send the ideal score of 1 ms to hack the game (this is indeed what a friend of mine managed to do).
The question(s)
The question is: how can I prevent this from happening?
Should I make a few changes in the code about the firebase configuration?
Should I use some other way to store the data, and not firestore?
Should I config properly the firestore security rules?
Also, what are the best security practices in JS frameworks like Vue.js (or React, in general) to prevent the insertion of non-wanted data on the client side? How do I manage the connection to a cloud database from such front-end frameworks?
Disclaimer
I learn everything about programming on my own, by watching youtube videos or googling and so on. I am new not only to Vue and Firebase, but to web development in general. Please consider this when answering.
TL;DR;
If the score is calculated on client-side (in browser) you can't secure it.
Anyone can just see the API call being made from the app to the server and replicate that with rest API tool like postman, so you wouldn't even need to download it locally to make changes.
If your game relies on client-side as a source of data, there is no way for the server to ensure that it is un-tampered.
You can try obfuscating the source code and doing client-side data encription, but it's all in javascript so everything is readable.
If you were to implement it in a more secure way, you would have the server trigger an action (as opposed to the script) but then the times would end up being longer because of the data turn-around time. Since the event fired from server to client and back would be reflected, but even then the automated response can be hacked by handling it with a script.
(this was originally a post on the flutter-dev reddit that was redirected here)
So I started making this flutter app using firebase as a backend and after looking at all the options for state management I finally realised that the tools provided by firebase already handle pretty much everything I would need state management for.
For example:
I could set the currently logged in user in my state to show the right login or home page and make the user uid available to widgets for their firestore API calls.
OR
I can just listen to FirebaseAuth.instance.onAuthStateChanged to show the right page and just use FirebaseAuth.instance.currentUser() from anywhere to get the logged in user uid and do my firestore calls.
What I mean is, for every thing that would require global state, I can just basically have a firebase stream listener.
Is this right ? Or am I missing something here ?
You're not missing anything. Since most Firebase APIs rely on data from Google's servers, many of them are designed to be used in a reactive way. Making your UI reactively respond to those asynchronous changes is (in my experience) the best way to keep your code simple.
There may be slight behavior between the different types of listeners. But the onAuthStateChanged listener immediately fires with the current state when you attach it, which makes it a good example of a listener that you can use everywhere you need to respond to auth state (instead of also storing that state somewhere in your app).
In that scenario I would say yes, you can read the onAuthStateChanged stream and react to changes. But there are also scenarios where I need a stream for interacting between widgets without a parent/child relationship. For example, in one of my apps I have a company selector, and the rest of the app reflects to the selected company. I created a stream, so that the company selector doesn't need to be a parent of the other widgets, and especially so that I don't need to pass the company parameter to all the widget tree.
I also have one scenario where I need to load extra information about the user that isn't available on the FirebaseUser object. So when the user is logged on I load their information from a "users" collection and then I add that to a custom stream.
So to conclude I would say yes, you should use the default Firebase streams when possible, but that doesn't mean you can or should use that solution for everything.
I am hoping this is not too off topic for a post here.
I have an asp.net webAPI service, which provides a number of routes to get near realtime data (ie within say 10 seconds), which required the client application to poll for changes.
I am investigating on which technology would be best to add an "opt in" push notification service, which just pushes "thin" payloads to tell the client application it is now time to call the existing REST route for an update. This way, the push payload is small, and does not contain any security sensitive data (it still gets this using the existing REST security infrastructure)
Cloud based messaging
Previously, I have been told that, for a Mobile application, I should use something like Firebase cloud messaging, or some other messaging service, however this does not seem like the right solution for "subscription based notifications" I am talking about here. I can certainly see this would be useful, if the client is on either iOS or Android device, and wanted messages/notifications/alarms (etc), which could also work when the application is not running, but this does not seem like the right thing to use of these notifications of changed data (which may be happening all the time, sometimes every 5 seconds). Also, I do not want to only target these mobile devices, but also, for example either a web or desktop application, which may also use the same REST service
Other technologies
I have seen mention of Web sockets, or, in the case of asp.net, the option to use SignalR (which will wrap the web sockets, with fallback). SignalR looks good, but my worry is the availability of client libraries for non web / Windows applications (eg iOS, Android). I am also looking at Rest Hooks. These look interesting, but I can't quite see what the actual "push mechanism" is; it almost looks like they need to POST to the subscriber using HTTP, which means the subscriber has to also act as a "server endpoint".
Just after any thoughts / best practices on this, or what others have used?
In particular, (the verification or otherwise), that for this use case, using cloud based messaging is not the right thing to use due to the frequency of these push notifications (ie something where my server gets to the application via another 3rd party service which pushes to the device/application)
Thanks in advance for any suggestions!
Signalr is an option
There are some libraries which you can use in iOS and android. I suggest you to read once https://visualstudiomagazine.com/articles/2013/11/01/how-to-use-signalr-in-ios-and-android-apps.aspx (its a bit older, but on the point)
Android Client: See How to use signalr in Android
Some alternatives :
Pusher (https://pusher.com/)
Android Client: https://pusher.com/docs/android_quick_start
iOS Client: https://pusher.com/docs/ios_quick_start
Socket.IO (https://socket.io/)
Details iOS Client: https://socket.io/blog/socket-io-on-ios/
Details Andriod Client: https://github.com/socketio/socket.io-client-java
To discuss:
Why you will only send a thin payload whith signalr? I see no benefit for that.
Why "using cloud based messaging is not the right thing"? I do not understand your arguments but I do not know how your application looks like.
All,
I have completed the basic GAE "Guestbook" example which uses Google Cloud Endpoints and Google Cloud Messaging. I can successfully add a note to the guestbook and have it appear on all registered devices.
I've also used the super simple Server Sent Event (SSE) mechanism to have a web page initiate an event source and then update itself as events are received. But separate web pages appear to create their own distinct event sources (even if using the same URI to the event source) and thus get their own events at their own times.
The objective here is to create a bit of collaboration such that user actions can come from an android device or a web page and the effects the received action are then pushed to all connected users/devices/web pages.
I have assumed I will need a background module and that both Endpoints and 'normal' web pages / queries would channel the received user action to that background module. I believe I can get that far. Next, I need the background module to trigger a push notification to all interested parties.
I believe I can trigger a Google Could Messaging event to registered Android devices from that background module.
But it isn't clear to me how a background module can be the source of an SSE, or how the background module can best communicate with a foreground module that already is the source of an SSE.
I've looked at the Google Queue API, but I have a feeling I'm making something quite easy much more difficult than it needs to be. If you were not going to 'poll' for changes from a web page... and you wanted to receive notifications from an SSE source when changes were made by other users, possibly using Android devices rather than a typical web page, and the deployed application is running on the Google Application Engine, what would you recommend?
Many thanks,
Randy
You are on the right track, not really sure why you are using the background module but from what i understood you need to:
Your front end module receives an update
You retrieve a list of all devices receiving that update
Use the Queue service to send the update via GCM to every single device
Why use queues? because front end instances have a 1 min time limit per request and you'll need to queue work in order to go beyond that time to serve you (potentially) thousands of users.
Now, If you already have a backend instance (which does not have the 1min limit) you could just iterate over the list and send all messages on one request. I believe you have a 24 hr request limit so you should be OK. But in this scenario you don't have need for the front end module, you can just hit this server straight up.
We have an ASP.NET website where user adds items to database.
There are several sites on same server, each with its own database.
I need to implement a mechanism to check database for the state of each item.
If item is unprocessed, submit it to a third party web-service.
I see two options:
put the code in a webapp
put the code in a Windows service
The first option has the advantage that the code knows which database to connect to.
With Windows service, it has to be aware of all databases, so it's harder to maintain. Also, if I have only one Windows service, it will have to use threads to process items in each database in parallel.
Maybe there's another way beside these two?
What are the other issues, and what would you recommend?
Please explain your choice.
This sounds like a good place for a message queue to be involved. Each item would be wrapped into a message and placed in the queue. The "item processor" (a service?) would subscribe to the queue and perform some work using each item as it arrives. How the messages get placed on the queue is up to you, but for an example you could have each site publish the "new item" message to the queue.
Queues can be a bit of an intimidating concept at first, but frameworks such as MassTransit can help. Well worth learning.
I believe Windows Service is a good option compared to a web app, mainly because a web app would have to be triggered manually by someone, while a Windows Service can be running at all times, checking for updates.
There's another option, if you have access to each of the existing site's code. Why not write a Web Service that will submit data to your third party web service. Then in each of the existing web sites, modify the logic that stores changes in the database to also post the changes to your custom Web Service (or even skip the custom WS and call the third party directly).