Mixing
How do I make Firebase HTTP restful calls using just an API key?
I need to make restful calls to a specific area of my firebase database. The call needs to be made as an unauthenticated user, but I want to secure it using an API_KEY in the header to prevent bots from trawling the data. The database rules will make the data read-only to un-authenticated users. How can I only permit HTTP calls to read data using an API key in Firebase ?
I have found this section on Authentication requests but I need to make raw HTTP requests and cannot use the supported SDK methods in the examples provided.
firebase firebase-realtime-database api-key
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
add a comment |
I need to make restful calls to a specific area of my firebase database. The call needs to be made as an unauthenticated user, but I want to secure it using an API_KEY in the header to prevent bots from trawling the data. The database rules will make the data read-only to un-authenticated users. How can I only permit HTTP calls to read data using an API key in Firebase ?
I have found this section on Authentication requests but I need to make raw HTTP requests and cannot use the supported SDK methods in the examples provided.
firebase firebase-realtime-database api-key
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
add a comment |
I need to make restful calls to a specific area of my firebase database. The call needs to be made as an unauthenticated user, but I want to secure it using an API_KEY in the header to prevent bots from trawling the data. The database rules will make the data read-only to un-authenticated users. How can I only permit HTTP calls to read data using an API key in Firebase ?
I have found this section on Authentication requests but I need to make raw HTTP requests and cannot use the supported SDK methods in the examples provided.
firebase firebase-realtime-database api-key
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
I need to make restful calls to a specific area of my firebase database. The call needs to be made as an unauthenticated user, but I want to secure it using an API_KEY in the header to prevent bots from trawling the data. The database rules will make the data read-only to un-authenticated users. How can I only permit HTTP calls to read data using an API key in Firebase ?
I have found this section on Authentication requests but I need to make raw HTTP requests and cannot use the supported SDK methods in the examples provided.
firebase firebase-realtime-database api-key
firebase firebase-realtime-database api-key
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
edited Nov 20 '18 at 3:26
giulio
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
asked Nov 20 '18 at 3:15
giuliogiulio
5,31884470
5,31884470
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
What you're trying to do isn't possible. Realtime Database doesn't have dedicated API keys that can be controlled by security rules. Your database has one (legacy) private key that effectively gives the user full access to everything in the database. You're not supposed to use that any more.
The other form of authentication is the one you linked. You're going to need to perform OAuth2 authentication to get a token that belongs to a Google user account or a Firebase user account. You use that token in your raw HTTP requests.
There is no other way to specify any sort of special access to the database that can be controlled by security rules. Without using either of these above two methods, you are effectively bound to read only data that security rules have allowed as fully public.
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
1
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
add a comment |
A simple way to designate a specific unguessable path in your database for access by this client, and allow public read/write access there. For example:
{
"rules": {
"content_4287dhicer29pr2sdkuyfweuf": {
".read": true,
".write": true
}
}
}
Now anyone who knows this key content_4287dhicer29pr2sdkuyfweuf can read/write it, but only those people who know it. And since the key is quite unguessable, it is very unlikely anyone will be able to find it without getting it from you. Well OK, maybe you can come up with a better way to generate token than bashing your hands on the keyboard. :)
What we've done here is essentially embedding the API key into the key in the database. So instead of being in a header in your request, it is now in URL.
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385689%2fhow-do-i-make-firebase-http-restful-calls-using-just-an-api-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
What you're trying to do isn't possible. Realtime Database doesn't have dedicated API keys that can be controlled by security rules. Your database has one (legacy) private key that effectively gives the user full access to everything in the database. You're not supposed to use that any more.
The other form of authentication is the one you linked. You're going to need to perform OAuth2 authentication to get a token that belongs to a Google user account or a Firebase user account. You use that token in your raw HTTP requests.
There is no other way to specify any sort of special access to the database that can be controlled by security rules. Without using either of these above two methods, you are effectively bound to read only data that security rules have allowed as fully public.
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
1
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
add a comment |
What you're trying to do isn't possible. Realtime Database doesn't have dedicated API keys that can be controlled by security rules. Your database has one (legacy) private key that effectively gives the user full access to everything in the database. You're not supposed to use that any more.
The other form of authentication is the one you linked. You're going to need to perform OAuth2 authentication to get a token that belongs to a Google user account or a Firebase user account. You use that token in your raw HTTP requests.
There is no other way to specify any sort of special access to the database that can be controlled by security rules. Without using either of these above two methods, you are effectively bound to read only data that security rules have allowed as fully public.
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
1
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
add a comment |
What you're trying to do isn't possible. Realtime Database doesn't have dedicated API keys that can be controlled by security rules. Your database has one (legacy) private key that effectively gives the user full access to everything in the database. You're not supposed to use that any more.
The other form of authentication is the one you linked. You're going to need to perform OAuth2 authentication to get a token that belongs to a Google user account or a Firebase user account. You use that token in your raw HTTP requests.
There is no other way to specify any sort of special access to the database that can be controlled by security rules. Without using either of these above two methods, you are effectively bound to read only data that security rules have allowed as fully public.
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
What you're trying to do isn't possible. Realtime Database doesn't have dedicated API keys that can be controlled by security rules. Your database has one (legacy) private key that effectively gives the user full access to everything in the database. You're not supposed to use that any more.
The other form of authentication is the one you linked. You're going to need to perform OAuth2 authentication to get a token that belongs to a Google user account or a Firebase user account. You use that token in your raw HTTP requests.
There is no other way to specify any sort of special access to the database that can be controlled by security rules. Without using either of these above two methods, you are effectively bound to read only data that security rules have allowed as fully public.
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
answered Nov 20 '18 at 3:32
Doug StevensonDoug Stevenson
72.3k983103
72.3k983103
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
1
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
add a comment |
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
1
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
thanks for jumping in quickly. So, I only want access to a specific branch of my database that has a list of ID's to validate. The data itself is not sensitive, but the user is unauthenticated at this point in the process. So, I was hoping to use something like the legacy tokens at this point as there is no "user" and only apply it to a specific branch within the database
– giulio
Nov 20 '18 at 3:43
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
The legacy private key would allow anyone who uses it to read and delete your entire database without having to know anything about it other than its name. You wouldn't want to bake this into your app, as it would essentially be public data at that point.
– Doug Stevenson
Nov 20 '18 at 3:48
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
Taking your advice about the security risks, I created a public cloud function that interrogates the list and returns a boolean in the response. Therefore you need to make a request with an id to determine if it's already registered in the database and prevents exposing large volumes of data publicly
– giulio
Nov 20 '18 at 5:20
1
1
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
And if that ID is baked into a publicly accessible mobile app, the information and everything behind it is essentially public. The technology stack doesn't really matter.
– Doug Stevenson
Nov 20 '18 at 5:30
add a comment |
A simple way to designate a specific unguessable path in your database for access by this client, and allow public read/write access there. For example:
{
"rules": {
"content_4287dhicer29pr2sdkuyfweuf": {
".read": true,
".write": true
}
}
}
Now anyone who knows this key content_4287dhicer29pr2sdkuyfweuf can read/write it, but only those people who know it. And since the key is quite unguessable, it is very unlikely anyone will be able to find it without getting it from you. Well OK, maybe you can come up with a better way to generate token than bashing your hands on the keyboard. :)
What we've done here is essentially embedding the API key into the key in the database. So instead of being in a header in your request, it is now in URL.
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
|
show 1 more comment
A simple way to designate a specific unguessable path in your database for access by this client, and allow public read/write access there. For example:
{
"rules": {
"content_4287dhicer29pr2sdkuyfweuf": {
".read": true,
".write": true
}
}
}
Now anyone who knows this key content_4287dhicer29pr2sdkuyfweuf can read/write it, but only those people who know it. And since the key is quite unguessable, it is very unlikely anyone will be able to find it without getting it from you. Well OK, maybe you can come up with a better way to generate token than bashing your hands on the keyboard. :)
What we've done here is essentially embedding the API key into the key in the database. So instead of being in a header in your request, it is now in URL.
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
|
show 1 more comment
A simple way to designate a specific unguessable path in your database for access by this client, and allow public read/write access there. For example:
{
"rules": {
"content_4287dhicer29pr2sdkuyfweuf": {
".read": true,
".write": true
}
}
}
Now anyone who knows this key content_4287dhicer29pr2sdkuyfweuf can read/write it, but only those people who know it. And since the key is quite unguessable, it is very unlikely anyone will be able to find it without getting it from you. Well OK, maybe you can come up with a better way to generate token than bashing your hands on the keyboard. :)
What we've done here is essentially embedding the API key into the key in the database. So instead of being in a header in your request, it is now in URL.
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
A simple way to designate a specific unguessable path in your database for access by this client, and allow public read/write access there. For example:
{
"rules": {
"content_4287dhicer29pr2sdkuyfweuf": {
".read": true,
".write": true
}
}
}
Now anyone who knows this key content_4287dhicer29pr2sdkuyfweuf can read/write it, but only those people who know it. And since the key is quite unguessable, it is very unlikely anyone will be able to find it without getting it from you. Well OK, maybe you can come up with a better way to generate token than bashing your hands on the keyboard. :)
What we've done here is essentially embedding the API key into the key in the database. So instead of being in a header in your request, it is now in URL.
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
answered Nov 20 '18 at 3:42
Frank van PuffelenFrank van Puffelen
230k28376400
230k28376400
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
|
show 1 more comment
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
thanks for that. I like this idea, but would this unique path be exposed to anyone watch the calls ? ie it can be hacked if someone is watching the domain ?
– giulio
Nov 20 '18 at 3:47
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
If this node name was baked into code that ships to public clients (in an app website, or otherwise), then it's effectively public information, and anyone would be able to discover it and have full control over it.
– Doug Stevenson
Nov 20 '18 at 3:50
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
@DougStevenson would it be better to simply lock the data down, and have a public cloud function that processes a request ?
– giulio
Nov 20 '18 at 3:54
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
I don't see how that's effectively any different than just giving direct access to everyone in security rules. If you bake any sort of private information into a public app (api key, password, credentials, whatever), it's effectively public information and may be abused.
– Doug Stevenson
Nov 20 '18 at 4:05
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
It is no different from your proposal with an API key though. There too anyone with access to the app could take that API key and make calls. The only way to prevent that is by authentication the user and securing data access based on that.
– Frank van Puffelen
Nov 20 '18 at 4:32
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53385689%2fhow-do-i-make-firebase-http-restful-calls-using-just-an-api-key%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
