I'm trying to use fetch method to get/post data into a REST server (this is working), but some users of my app need to do this over a network(WiFi) with proxy authentication. I've searched this, I found a few answers, but no one have helped me, some doesn't work 'cause need the Node core modules (that isn't on React-Native packager), e.g: https-proxy-agent.
Here I've found a similar question: react-native-fetch-through-proxy, but axios don't supports proxy with user and password (I tried), and the unique answer doesn't worked for me, 'cause it need Node core modules (again).
I tried browserify to implement pieces of Node core, but the https-proxy-agent plugin can't see my JS files.
Related
Im new to backend dev, and I have a full fledge working React app that GETs,DELETEs and PUTs data using a fake server. Now I need to use an actual backend and I was thinking of going with Firebase as it seems really convenient. However I saw some examples using Firebase directly in the React app, and some using Node.js to do the work.. Could someone please tell me whats the best way to go with this? If there's an easier way to create REST API using express/mongo, I am also open to those :)
You have to keep in mind that anything you do from the frontend will be visible to the user, so communicating with Firebase from React will be a bad idea at least for anything involving sensitive information (passwords, credit card info, etc.). Just because you can do something doesn't mean you should. Use a Node backend and use that to communicate with your DB and other services.
To address the last part of your question, it is possible that Firebase might be more than you need. A simple setup with Express and MongoDB might be easier. MLab has a pretty good free sandbox database-as-a-service that requires very minimal setup.
I think firebase can also be a good fit, you can use Firebase auth to manage authentication and Rules in the Realtime database or in Firestore to prevent not authenticated users to manipulate your data https://firebase.google.com/docs/database/security/ And to get the best out of Firebase I would recommend using the SDKs but you can also use the REST API https://firebase.google.com/docs/reference/rest/database/
Also if you want to have functionality on the backend you can do so With Firebase Admin SDK https://firebase.google.com/docs/reference/admin/
From my point of view that is one of the advantages of firebase, you can get con going really fast without having to worry about managing infrastructure.
I'd like to make a small web app using only client side javascript, that is publicly available on GitHub and hosted via GitHub Pages, that renders information about the different repositories of an organization on GitHub.
Is this possible to do in such a way that:
allows me to authenticate with GitHub without compromising a secret key,
allows me to query GitHub's new graphql api?
In both cases, the docs seem to suggest that the answer to my questions are "no" and "no":
for example, the authentication docs emphasize how to authenticate on the CLI, but I don't find anything on authenticating from a web page via javascript -- is there really no way to do this securely from only the client? Is a server required for this?
for example, the api v4 docs seem to only mention how to call the graphql endpoint via cURL or by using their GraphQL Explorer
I'm seeking guidance here in the hopes that I'm misreading the docs, and that there really is a way to:
build a static-site that authenticates with GitHub for the increased query rate limit size,
and that, when a user visits the page, queries the v4 api and displays the appropriate information about the current status of the various repos of an organization.
I ignored the documentation and just submitted a POST with a Basic Authorization header. It seemed to work. I found the other issue. Github wants a User-Agent header. If you are running in a browser that happens automatically, but if you are not you need to add it yourself. Github documents what should be in it, but apparently does not validate it.
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html
I just installed the MEAN stack (MongoDB, Express.js, AngularJS, Node.js) and opened up the example program (as found on mean.io) and they have a basic app that you can login to and create blog "articles" just for testing and such.
Anyway, I removed the '#!' from the URL and it outputted the entire user and article models as they are in the database. It seams as though doing that made it stop routing through Angular and instead used the Express routes which are just JSON REST apis. Is this a flaw in the MEAN stack package, Angular as a whole, or maybe just a development environment setting? I can't imagine that this would be released with a huge flaw like that but maybe I'm just missing something..
Replicateable steps:
Follow installation instructions on http://mean.io
Goto your local app in the browser and create an account and login
Create an article
View the article item you just created and remove the #!/ from the URL, you then see the JSON object of your logged in user account
complete with hashed password and salt, as well as the article
object.
Its just an app configuration. If you change the routes.js from:
app.get('/articles', articles.all);
to
app.get('/articles', auth.requiresLogin, articles.all);
Then if you try and hit the url /articles directly you get the message:
"User is not authorized"
Instead of JSON listing all the articles.
As you say, removing the #! causes the routing to be handled by the server. The node API then dumps the user object in the response.
The problem is completely independent from Angular - the app is only served by Node at the / route. Angular then uses the hash value to show the correct page.
This is probably just a problem with the example provided by MEAN. The app itself is insecure, when they talk about best practices that refers to the code structure and setup rather than the quick demo.
You could ask them about it, since there will probably be people who build on top of the example and don't fix the security issues.
I am trying to allow users to upload large files without tying up my servers for an extended amount of time. I thought using dropbox as file storage might be a good solution. My plan is to use javascript to have the client-side connect directly to dropbox, so that my server is not affected.
I have been trying to find a current javascript dropbox api, but have not had much success. I tried using dropbox-js, but it seems that it is using an outdated version of the API as I get the following error with my current test: {"error": "You're using an older version of the Dropbox API with a new API key. Please use the latest version."}
Does anyone know a fairly simple way to accomplish this task?
Set up your application as a Folder app. If things go wrong, at least you won't blow up people's Dropboxes.
Follow these directions for obfuscating your API key and secret.
Use writeFile to upload the files, and then use makeUrl with the downloadHack: true option, then send the URL to your server.
You'll need the git version of dropbox-js to use downloadHack until the 0.7.0 release comes out.