im new to Node and React. Now i am playing with react and redux. It is awesome! But at least there is one question. Is the redux store user specifc or get every user the same obejct with the same values?
Edit:
In my scenario different User work with the App on the same time. Do they always have the same state. Is the state syncron between different users.
Or get every user an specifc state in redux.
Thanks!
React runs in the client-side as JavaScript, so by default each tab where your application is running has got its own state that has no guarantee to be the same.
To synchronize your state between your tabs of the same browsers, cookies can be used. To synchronize your state between your different users, they have to communicate with each others so some implementation has to be done on the client side, for example with sessions or websockets.
But keep in mind that there is no easy sync switch! State synchronization requires a lot of implementation and even if there might be some libraries that help with that, synchronizing the state between several instances of a React app requires possibly a lot of skills and code.
It's hard to go further in answering with the little amount of explanation you gave without speculating, but you got the gist.
Because React is served from the client (browser), the state of a react app belongs to the instance of the application itself.
So if you have 2 tabs open, each tab has its own instance of the application and therefore have their own state.
No matter if you are logged in as the same user within the app or different users, it's the application which has its state (unlike a session, which you would usually find on a backend)
The same applies to redux, the state belongs to the instance of the application.
I hope this provides some clarity
Related
The gist of it all is that I'm trying to fetch audio metadata from a user's google drive files to store them into firebase.
At first I intended to do this locally, entirely client-sided, because my front-facing web/iOS/Android app is in flutter;
but as it turns out, there's almost no library handling audio metadata properly, and after dabbling with it, I realized I could probably get some formats (say, .wav & most RIFF-type audio files) to work, but doing an entire library to handle all kinds of audio metadata was a task significantly bigger than my original plans. Another option would be to create interfaces between C++ code and/or JS code into my Flutter application, but I'd have almost no control over that, it's not the easiest of process, and there would be possible inconsistencies between platforms.
I might make that library eventually, but in order to facilitate my work, I decided to use a server as a middleman that'd run with node and handle the file requests and metadata treatment, & also facilitate the interactions with firebase for me by making them handled by a service account.
Now, this makes me run into one issue : how to handle the google Auth.
When my user logs into my app, I get all the required auth scopes (google drive files access and write, contacts, email, etc) for my app; it goes through the consent screen and I get authenticated.
I'm still a little confused with the recommendations from google and best practices in this case, since my app, in itself, did not require an auth system outside of getting access to the google drive files through google identification, and I therefore do not have Firebase/Firestore users; I can simply store them in my (firestore) database for identification purposes (or maybe tie in the frontend flow to my firestore app to also create a user when logging in through google if that is possible. I'm currently using the google sign in
flutter package.)
To come back to my actual problem now that the situation is laid out :
Should I just transfer the auth tokens (and maybe reverify them in some ways to avoid impersonation) from my frontend app to the server through a HTTPS post request or through headers, and use them to directly query the Google Drive API (I wouldn't even need to store them outside of memory, which would be relatively safe against any attacks on the server itself), handle the files and the possibly expired token ?
Should I modify my frontend workflow so it directly grants access to my server who would handle the session rather than getting the tokens locally ?
In the first case, I would most likely simply use the users UID as identifiers for the firestore data (none of it is sensitive anyway, it would simply be playlists and some metadata). In the second case, I could probably implement a stronger security on firestore using the firestore rules,but it'd require a significant amount of refactoring and logic changes in my frontend.
In case that wasn't clear, I wish my server to make all the Drive related requests (after getting the proper authorizations from the user of course) and handle these without having to request the files locally in frontend. Both solutions (and others if available) should work, but I'm wondering what the best practice would be in the context of the Oauth2 system used by google and the fact that the authorization is transitioning between client and server and could be subject to security issues.
I'll add code/visual representations if this isn't clear enough. It is to me, but I obviously designed the mess.
Im building a chat that uses a api rest full, but i found a problem storage jwt in client side (cookies and his problems), so i opted to use sessions(it's a better option in security terms), that adds state to my app.
I should create a separate server that handles the sessions and also have my rest api?, and apart another server that implements some functionality such as a push server (which I plan to implement). Because I really don't like the idea of having everything on one server, and if so, what should I take into account? (have more than an rest api server and other with his funcionality).
I'm a developer and i think so this require architecture knowledge, and i have no many idea about servers. If you can give me some idea about the topic to get better on it will be great, and what's the better option in this case.
Thanks, give a nice day
We have a web application that's built on top of Play framework 1. The current version of Play is 1.2.7. It's running on top on Ubuntu 12.04 in an Amazon EC2 instance.
Recently we experienced a peculiar and very worrying behaviour on our test server. There were only a few people using the system: a few developers and a few testers. What happened was that the session cookie of one user was given to two other users. Suppose you have users A, B and C using the system, each logged in as themselves. Suddenly what happens is that all of them seem to be logged in as user A, without any of them doing anything special.
Play is managing its own session cookie. Suppose the session cookie name is configured as XYZ_SESSION. When we saw this behaviour, I was able to inspect the session cookies of users A and B (C was in a different organization and site). The session cookie that B had was 100% same as A had. In this application, the session cookie is used to store user name, email address etc. So in practice, user B was suddenly having the same session as user A. I didn't inspect the cookie of user C, but the verbal report was that he suddenly was logged in as user A.
This was actually a second time this behaviour was observed with this application. The previous time was several months ago, and then a cludgy hack was developed to notice the situation and logout the user in question. However, the hack is not very maintainable or scalable, and we want to get rid of it. And preferably find the root cause for the issue.
The authentication logic of the application is implemented using OpenID4Java. However, when this behaviour occurred, all users were already logged in.
We have a theory on the possible cause of this behaviour. In the application, we have a BaseController class that inherits Play's Controller class and that is used as the base class of all controllers. In the BaseController there is some code that gets and puts to the session container. In the code of that class, the session is referred to as just "session", which means the static field in Play's Controller class. The assumption is that Play's enhancer will enhance the reference to use a ThreadLocal field in Scope.Session class. The enhancing would be done by Play's ControllersEnhancer class. However, when inspecting the code of method enhanceThisClass in ControllersEnhancer, it makes use of CtClass/getDeclaredMethods. In the comments for that method it says "The inherited methods are not included." I don't fully understand how enhanceThisClass gets called, so I'm not entirely sure how solid the theory is.
So, our suspicion is that in practice Play skips enhancing the code in this BaseController class, and the static session field in Play's Controller class gets used as plain as it is, and this combined with suitable scheduling of threads will cause the session duplication!
The problem is quite difficult to reproduce and thus we haven't this far conclusively verified that this is the cause for the behaviour we observed.
Anybody have any insights? Have seen similar behaviour with Play? Able to prove the theory right or wrong?
on my work we use play 1.2.7 in a lot of applications. Last month we see the same issue with Play. Two users with the same session. In our case the app is separated in two modules (catalog and checkout), the catalog was using 1.2.7 and the checkout's module 1.2.4. Because the difference between the modules Play! create the same session in each module and given this session to the users. I don't know if your app has the same structure as our, but if yes, i recommend you see this.
We are about to make another server for XPages applications. In front of it there will be fail over/load balance component (Microsoft Forefront, IBM Web server) that will redirect HTTP request to one of two cluster servers.
I suppose that scoped variables will be reinitialized in case of fail over - user is redirected to other server which will initialize XPage from scratch (GET) or subset of data (POST). Anything binded to beans/scoped variables will be lost (pager state, application specific data). This can cause odd behaviour to users: loss of entered data or opening of unexpected page. I am aware of fact, that this is highly depending on application design.
The situation can be very similar to expired session on one server - how to prevent loss of data in such case.
Are there any coding best practices how to avoid side effects of fail over from server to server?
While not a code best code best practise, you first need to configure your load balancer to keep users on the same session once started (probably_ using a cookie, so failover only happens when your box really goes down.
Secondly don't take scope variables to be there, always test for them - which is a good practice anyway since a session can timeout and loose its variables on a single server too.
POST will fail due to a lack of x-session, so you might resort to posting only via Ajax that can have an error handler.
You could consider to use cookies to capture state information.
I'm currently searching the best way for developing my next webapplication. I'm thinking about using Backbone.js and build a single page application. But I really can't imagine how to secure my app since nearly everything is done on client side. Of course I just could prevent the users from accessing my RESTful Api so they would not have access to my data. But all the view/model/collection/template js files are still accessible.
Or is there a known way to serve the js files with php (laravel), which would allow me to only serve the files I need for the respective user.
I just couldn't find a solution by searching the Web. But I just don't think that I am the lonely person who needs a clean and secure authentication method including different user rights.
Thank you in advance!
Your backend application will fetch data from a backend (= API), and probably send back some changes.
This code can't have "security holes / leaks" as long as your backend is secured.
If you are afraid of people stealing your code, you can always minify the JS (check grunt.js and almond.js for this)
To secure your backend you can make use of Laravel's auth class, and the auth filter as mentioned before.
Besides normal auth, you could implement roles, that you can assign to specific users, giving them more or less access to certain resources in your backend.
Here's the method I would try :
Separate the application in two parts.
One part - login via regular Laravel Auth on a separate page, and then when the user is logged in serve the single page app in a different view.
Wouldn't this work?
Web Services are no different than any other web application you build. At the end of the day you are exposing functionality to the client (which is also the attacker). It doesn't matter what the client is implemented in, if you expose dangerous functionality you will be hacked.
Have a session state, keep track of the user id and make sure that the user is only accessing resources they have been allowed to access.
I do not think that what JS/template files are exposed really matters. Essentially, you should only be allowing data interaction to authenticated users. Think of this as two separate applications.
The front-end application logs in, and a cookie is stored (or some other persistence is used).
The back-end application then uses the persistent authentication to validate every single user request for data, and every user action.
This way you don't have to worry about the security, the client can only fetch the data that the server allows it to, and, likewise, it can only interact with the data insofar as the server allows it. You shouldn't be relying on the client side for security anyway, even logged in, otherwise some malicious user could, conceivably, save all your frontend code and use it against you without authentication.