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.
Related
There is plenty of tutorials and articles on this precise question but each one contradict the previous one,
I'm trying to make a signup and login reactJs pages with Firebase js sdk on the frontend, that's what I found most of youtubers devs do,
And then I found that is not secure (doing the authentication on client side).
You should use the Firebase Admin SDK (firebase.google.com/docs/admin/setup) on Firebase Cloud Functions or a self-hosted server in that case. Everything else would just be a dirty hack – PRSHL source
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves. source
I really want to understand if it is not secure to use it on the client side, Why does firebase provided it in the first place ?? or is there another way to properly write the auth using firebase js sdk on the frontend ? of course without using admin sdk
Or should I use firebase js sdk on the backend with express ?
I only want clear and detailed answers please !!
My best guess is that you're confused between authenticating a user client-side and the fact that Firebase provides a client-side SDK for authenticating users.
Though all you have to do to use Firebase Authentication in your app is implement its client-side SDK, there are many more parts involved in the process - and quite a few of them run on secured servers.
It's just that Firebase (and the authentication providers it supports) have implemented the server-side of the authentication process for you already and made the variables parts of the process part of the configuration that you provide either in the Firebase console, the provider's web interface, and/or in the configuration that you specify when you initialize the Firebase SDK in your client-side application code.
From the comments you now added, the second is correct and explains exactly what the risk is:
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves.
So while you can safely create a user account on the client (a process known as authentication), marking them as an admin (a process known as authorization) has to happen in a trusted environment as otherwise any user could make themselves an admin.
I'm going to make a project using the Google translate api and I'm thinking of uploading this project to a server and just sharing it with my friends. But unfortunately the Api Key that I will use in the project can be accessed clearly in the JavaScript file. This is a very bad situation. To prevent this, I have limited the Google Cloud Api and as far as I understand it is only allowed to be used on the links I allow. It cannot be used on other links. Now my main question is, is this method enough to protect Api from malicious people? Do I need to do anything else? Thank you in advance for your answers.
Best practice in these cases is to use .env files to keep data like API keys private.
You have to create a server for that which will perform OAuth and then send an API request to google.
You can get help about how to implement OAuth from this topic provided by google: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
If you send/attach your API key in frontend like javascript which is basically a frontend language then it can be used to:
Send fake requests which will use all of the bandwidth etc.
You should also consult the TOS.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Like you I had an issue with the following line.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
That is however really only an issue if you are releasing the source code of your app as an Open source project for example.
If your just hosting this on a server then what you shoudl do is set up limitations for the api key adding_application_restrictions you can limit it so that the api key can only be used from your server and no where else.
I'm currently working on an application for myself in which I need access to my own photos/albums on Google Photos. I have gotten by using the oauth 2.0 token generated in the playground, but I'd like to get a more permanent solution that does not require me manually regenerating the token. Is this possible with Google Cloud? The app is meant to run in daemon, so this makes any option with consent pages unusable. The scopes I'm using are:
https://www.googleapis.com/auth/photoslibrary.sharing
https://www.googleapis.com/auth/photoslibrary.readonly.appcreateddata
https://www.googleapis.com/auth/photoslibrary.readonly
I have tried using the https://accounts.google.com/o/oauth2/token and https://accounts.google.com/o/oauth2/auth endpoints to generate one programatically, but the only minor success I had was /auth sending me to a consent screen. I've also looked at using the refresh token given by Google Oauth playground with no luck there either.
Just looking to see if there is anything that I am missing.. This is my first post on stackoverflow, so please let me know if you need any more information.
I was unable to make it an internal app as it was for personal use and not for an organization.
Solved this by first using the google api package to create my own access/refresh token for my oauth client, then calling the https://oauth2.googleapis.com/token endpoint each time to generate a valid access token. I hope this can be helpful to someone else!
According to the setup documentation, as long as your app is marked as internal, you should not need to verify the app and can use it without the consent screen.
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'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)