I am new to web development, but I am building a tool to help us visualize the customers in our database in a more concrete way (basically a CRM of sorts). Its a web app using a node.js backend and Vue.js for the front end.
THE BIG QUESTION - I found a connection.threadId query that can be run. If I save this threadID in a cooke or JSON web token, can I use this to have each user uniquely querying the database? If you need additional information on my issue, continue reading.
Essentially the problem I am running into is authentication. We were able to get a dummy user create that has read only privileges to the database, but this doesnt help the account management team. I am trying to find a way for them to be able to login with their own credentials and then be able to run queries from my node.js (javascript) backend using a series of get and post requests.
I am able to get the user to login with the SQL password and they can run the initial query (that fires upon login) but they then cannot re-query the database if someone else logs in after them (I realized that my variables were all globally scoped on the server.) I then moved everything client side in JSON web tokens, but I had to hash the database password to be safe which leaves me with another problem. My hash and the original database hash do not match, and that is not something I'll ever get access to. Not really sure where else to go with this at this point.
Please ask if you need any additional information to assist.
Thanks!
You probably can't.
You also probably shouldn't use variables on the SQL server for a web app like this. If you can refactor those into variables you can schlep around in the user session (or POST parameters or whatever), you're much better off, being more stateless (as far as the server components are concerned) and all too.
Related
Im coding a static page app using Angular, which shows various Instagram and Twitter posts of the company, and shows the details of the members. I have few questions regarding this, and would like any help.
Firstly, I have about 100+ contacts to display on the first page. Should I create a Json by myself and retrieve it from the service, or should I create a backend and save it there ? I do not have any backend as of now.
Other thing, I was able to retrieve Instagram Json with media content using their API, the doubt im facing is, once I have the call done, will the Json change automatically when the user adds/edits their posts? Or will the Json be the same as I first called it with? Any help is appreciated. Thanks.
For your case, as you have fewer data using Firebase is the best approach. If you write a backend and maintaining it would cost you more. You can use Firebase service URL to retire those records. In future, if you want to add more data it would be easy.My suggestion is Firebase.
Should I create a Json by myself and retrieve it from the service, or should I create a backend and save it there ?
Are you revealing credentials or other sensitive information in the client? That would be one reason to have a backend apart from Instagram or Twitter. Do you envision exhausting API rate limits of Instagram or Twitter APIs? That would be another reason; you could cache results in your backend to reduce external API traffic. Do you need to process (reduce? translate?) the data before it gets to the client, or are you satisfied with performing any processing on the client (e.g. is it fast enough)?
TL;DR: It depends a lot on your particular requirements.
If you do want a backend, the recommendation in the answer from #praneeth-reddy to use Firebase is excellent. If you only need processing/transformation but no caching or separate storage, then AWS Lambda may also be worth considering. If you need more control (build vs. buy), you could write your own backend.
...will the Json change automatically when the user adds/edits their posts? Or will the Json be the same as I first called it with?
Angular can help you update content automatically if the client side data (think browser JavaScript memory) changes via its automatic change detection functionality, but you would have to provide your own logic (e.g. in Angular services perhaps leveraging RxJS) to update the client side data based on data from the APIs. You could poll to update periodically, or for better performance listen for changes using an asynchronous event/push mechanism such as websockets or streams.
Okay, I have the following use case for Firebase:
Client wants us to store data from a form and put it into the DB. This is handled on the backend with Express.
This has to be done pretty quickly, so I just want to make sure I do it correctly.
I currently have the rules to allow read and write access to be true. Would this be okay in production, given that users can only input data through the form? And they wouldn't have access to the API key, so other users couldn't mess with the data?
From your description it sounds like you have:
{
"rules": {
".read": true,
".write": true
}
}
This means that anyone who can find the URL for your database (https://yours.firebaseio.com) can write to the database. It doesn't matter if they use your form, directly use a Firebase SDK or even if they just make a REST request using curl:
curl -X DELETE 'https://yours.firebaseio.com/.json'
This last line will delete your entire database. And all it takes is one malicious user or one typo while you're developing (this happens a lot more than you'd think).
So you really should set up your database security rules to:
validate that the data is in the correct format
make sure that only authenticated users can access the data that they're authorized for
Yes, having both read and write permissions set to true is a big security hole for multiple reasons:
Public read access creates a privacy problem for your users if you handle any personal information.
It is also a breach of confidentiality with your client if you expose their business data to the public without their consent.
Public write access allows anyone with your database URL to delete or modify its contents at will.
Also note that if your app exposes Firebase through its front-end to the users, getting your database URL is as simple as reading through the app's HTML source.
What you can do, however
is authenticate your app through the server side and set private access to the database. Take a look at how to create a service account, also detailed here.
If you use an older version of firebase, you will have to use server tokens
Hope this helps!
I'm trying to make a user log in just once, and have his information on all the servers. Any changes made to the user's information will instantly be available for all servers. Is this possible to do without having each user "log in" separately for each server?
Sort of like the $_SESSION for php, but for Node.js
Design 1 -
What I think would be best to do, but don't know how to share socket data between servers, perhaps using something like PHP's $_SESSION?
Design 2 -
What I'm currently doing:
User uses socket.emit to main.js
main.js adds user information onto the emit
main.js emits to the appropriate server
Appropriate server emits back to main.js
main.js finally emits back to user
This seems awfully inefficient and feels wrong
If your information is primarily static, you can try something similar to JWT. These are cryptographically signed tokens that your authenticating server can provide and the user can carry around. This token may contain information about the user that you want each server to have available without having the user accessing it.
If it's not, you may be looking into sharing a database across all servers, and have that be the point of synchronization between them.
Updates based on our comments (so they can be removed later):
If you decide to use auto-contained JWT tokens, you don't need to be making trips to the database at all. These tokens will contain all the information required, but it will be transparent to the end user that won't have insight into their contents.
Also, once you understand the JWT standard, you don't necessarily have to work with JSON objects, since it is just the serialization approach that you can switch by another one.
You'd provide one of these tokens to your user on authentication (or whenever required), and then you'd require that user to provide that token to the other servers when requesting information or behavior from them. The token will become your synchronization approach.
I have been working on a large project for about 4 months.
We have a "lead" that I constantly question.
The rules of the project (from the customer who has no background in IT) are
Only JavaScript will be used (Kendo UI package for CRUD).
It is to be "secured" with SSO - ADFSv2/ACS
It must have use Odata to interact with the database.
Please correct me if I am wrong, but does this not mean
A. This is clearly insecure. (after the initial login)
B. How can Kendo even handle database interaction (correctly) if it must update multiple tables?
There is another programmer currently working on a similar project and he is using Node.js for a web app that interacts with a Database.
Doesn't this suffer from a similar issue?
How does this client side CRUD work security and accurately?
Correct me if I am wrong, but it seem to me that you think that javascript directly access the database.
For that I see, Javascript is only used to manage the UI, and to contact (with Ajax ?) the server to update/create/delete entities.
It isn't insecure, but developers must ensure that the requested user's action is permitted (on server side).
Example : For a DELETE requested URL like https://myServer/myApp/Person/1, an user can modify this URL like https://myServer/myApp/Person/6 or https://myServer/myApp/Work/1.
So it must be verify that the user can delete a Person with id=6, or a Work with id=1.
I have a client who would like the most recent post displayed on their site (along with like and comment counts) plus a link to the actual post. Their page is public, so I can view it in a browser without being logged in. Let's just say it's Nike.
http://www.facebook.com/nike (public)
http://graph.facebook.com/nike/feed (wait, i need to authenticate to see this?)
I went through the trouble of setting up a dummy app on a dummy account, got an access_token an was able to pull what I needed using javascript(Jquery). The reason I'm doing it this way is because the client has sensitive data and other apps/sites on this server and does not want to involve their IT department to QA my code.
Before final handoff, they'll likely set up their own facebook app on their account. This would significantly raise the stakes if someone decided they wanted to play with that access_token.
I'm mostly a front-end guy who's done some small php sites/apps, so what would you recommend I do?
Thanks for your time!
I don't know about facebook in particular, but typically if you want to protect api access credentials you would proxy the request through your server, and just send the results to the client (so the access key only exists on the server). Alternately, and I'm not sure that facebook provides this, some APIs will give you a user token, which does not expose your access key, but allows the client to call the api.