Accessing objects in google cloud storage bucket via API key - google-cloud-storage

I am trying to access content in a google cloud bucket via a Javascript running in a web browser. So far I have created signed urls on the server using the service account credentials and passed them to the client during REST calls. The only reason I am doing this is because I attempted to solve this problem before and then just gave up and opted for signed urls. Now I need to get this to work.
So far I have tried creating an access token on the server using the service account credentials like so:
credential = GoogleCredential.fromStream(this.getClass().getResourceAsStream("/serviceaccount.json"));
LinkedList<String> list = new LinkedList<String>();
list.add("https://www.googleapis.com/auth/devstorage.read_only");
credential = credential.createScoped(list);
credential.refreshToken();
Then I passed the "access_token" returned form credential.getAccessToken() to the client and used it in XmlHttpRequest like so:
var xhr = new XMLHttpRequest();
xhr.open('GET', "https://storage.googleapis.com/....." true);
xhr.responseType = 'arraybuffer';
xhr.setRequestHeader('Authorization', 'Bearer ' + access_token);
This causes chrome to produce the following error.
"Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource."
Cors on the bucket is
[{"maxAgeSeconds": 3600, "method": ["GET", "HEAD", "DELETE"], "origin": ["http://www.voxxlr.com"], "responseHeader": ["O
rigin", "Content-Type", "Content-Length"]},{"maxAgeSeconds": 3600, "method": ["GET", "HEAD", "DELETE"], "origin": ["http
://voxxlr.com"], "responseHeader": ["Origin", "Content-Type", "Content-Length"]}]
Next I tried to use an API key as follow:
var xhr = new XMLHttpRequest();
xhr.open('GET', "https://storage.googleapis.com/....?KEY=...." true);
xhr.responseType = 'arraybuffer';
That produced the following error:
AccessDenied
Anonymous users does not have storage.objects.get access to voxxlr/1511465797269/n.bin.
Shouldn't the API key provide access just like that? I am not really looking for a solution that includes the google/javascript clients since the only operation required is too read the bucket contents. No admin or delete functions are necessary. I am basically just looking for a solution where all html/javascript from my domain can have read access the buckets.
Any help would be appreciated... This has been eating up a lot of time, but it seems there should be an easy solution.

API keys are not an authentication mechanism. They provide a mechanism for indicating which project your request is associated with (which is used for a variety of purposes, notably quota and billing for unauthenticated requests), but successfully using one does not associate your request with any specific account or permissions.
Your CORS issue could be a variety of things. I notice there's a space in your specified O rigin header and in http ://voxx. Is that an artifact of copying to SO or is it how the real policy is? Also, origins need to be really specific; are you using HTTPS? If so, you'll need to include it. Also it might be a good idea to include the preflight request itself (OPTIONS) as one of the allowed methods.
Finally, you very likely do not want to be passing an access token to the client. An access token is only good for a few minutes, but it can be used to do anything the creator of the token can do (within its declared scope). That's probably something you really don't want. Signed URLs are a much safer idea.

Related

OAuth2 with SPA + REST API

Lets say we have SPA written in Angular 2 and have REST API using Spring Boot.
Both of them deployed in different servers. And now I have to protect this API via Facebook's OAuth2, but I don't know which grant type suits to my problem.
I don't want to be an auth server, I don't want facebook to be my resource server, instead my own REST API is supposed to be a resource server.
From FB I just want username or email or some identifier.
If I understood correctly I have to use implicit grant flow, because it's not a web application, correct me please, if I'm wrong.
Does "authorization code" grant also could be a choice ?
I really read almost all the threads related to oauth, spring security..
But I didn't find any info related to exactly SPA and REST API for separate servers.
Any link/resource related to above problem is appreciated.
Thanks in advance and sorry if I did something wrong, it's my very first post here.
You need to implement Implicit Grant flow https://oauth2.thephpleague.com/authorization-server/implicit-grant/
you need HTTPS for safety.
example:
OAuth Server: https://myoauthserver.com
restapi: https://myrestapi.com
client: https://myclient.com
send a get request to oauthserver "authorize" url with params
response_type = token (sometimes 'code')
redirect_uri = myclient.com or myclient.com/something (the one u assign while making an oauth client )
client id = dfuvhiurehvher (whatever id)
some providers require additional parameters like "scope".
when you send a request if everything works. you will be redirected to your client with the token in the url.
your request:
GET: https://myoauthserver.com/oauth/authorize?response_type=token&redirect_uri=https://myclient.com&client_id=yourClientIdHere
if successful you'll be redirected to
https://myclient.com?token=yourTokenValueIsHere
you can now use javascript to retrieve and store token value maybe to localStorage and attach it when sending requests to restapi (https://myrestapi.com)
heres an example request from auth0.com
$.ajax({
cache: false,
url: "http://localhost:7001/api/appointments",
headers: { "Authorization": "Bearer " + ATTACH_YOUR_TOKEN_VALUE_HERE }
});
for more details check this
https://auth0.com/docs/api-auth/tutorials/implicit-grant

Adobe CQ 5 Accepts Arbitrary POST Request

i know that Adobe CQ 5 was built on top of Apache Sling (which using JackRabbit). I'm a bit baffled as for why the website will accept arbitrary POST request from outside (unauthenticated user) into Publish Instance through the Dispatcher and then reply with HTTP 200 Content Updated. Should not content update only allowed from Author Instance in this case? Should not such request met with HTTP 403 response instead? - Why is it that even not logged in can get HTTP Response 200?
The response looked like this:
{
"changes": [],
"referer": "http://www.example.com/content/somesite/en.html",
"path": "/content/somesite/en",
"location": "/content/somesite/en",
"parentLocation": "/content/somesite",
"status.code": 200,
"status.message": "OK",
"title": "Content modified /content/somesite/en"
}
I've set POST Referrer Filter for now to prevent arbitrary POST request 'outside' the website got accepted, however i can still get this response by typing jquery ajax request in the browser console while opening the website.
I do wonder if this is bad or something, really new to Adobe CQ.
The JQuery Script for testing it is actually only these:
$.ajax({
url: 'http://www.example.com/content/fasfas',
type: 'post',
data: {},
headers: {
Accept: 'application/json',
},
dataType: 'json',
success: function (data) {
console.info(data);
}
});
Thanks in advance!
This is an issue of not taking the necessary steps to secure the AEM servers. There is a security checklist provided by Adobe to ensure that AEM installation is secure when deployed. Similar security checklist for the dispatcher is also present.
As for your case, there are few issues which are evident
The filter configuration within the dispatcher doesn't deny POST
requests, thereby allowing them to pass through the dispatcher and reach the AEM instance.
The anonymous user in the AEM publisher seems to have more than just
READ privileges on the repository thereby allowing him to make changes to the repo using POST requests.
The referrer filter configuration was allowing requests from external systems as well (which you have blocked now).
Your dispatcher should block all POST operations on the publisher. This is recommended in Adobe's official documentation for configuring dispatcher.
Publisher should also disable write permission for anonymous users and everyone group to paths that are not allowed to be modified by community. Unless you are using CUG, write should be disabled for anonymous across the publisher instance.

Force POST form submission to send cookies

I'm working on a feature for a Chrome extension which requires making a same-origin POST request to an endpoint. For brevity, I'll leave out the particular details of the website. This request creates a resource of a given kind. I've succeeded in being able to create many kinds of these resources, but there's one type in particular that always fails.
When you use the website's own UI to create this kind of resource, I noticed that the resulting POST request is sent with the cookie header, along with some other stuff that looks unfamiliar to me. Here's an excerpt of the request headers:
:authority:www.example.com
:method:POST
:path:/path/to/endpoint
:scheme:https
[...]
cookie: [...]
The cookies are not sent for any other resource type, just this one.
Now, since this passes along cookies, the website's own javascript can't be using ajax. In fact, the site is posting to an <iframe> by linking a <form> to an <iframe> of a particular name.
So, I modified my Chrome extension code to use forms to post to iframes instead of making an ajax request, just like it's done natively on the website. However, the resulting POST requests still do not pass cookies. I have found nothing unique about the parts of the website's UI which create these special resources which might cause the requests to pass cookies.
How does Chrome decide when to pass cookies in a web request? How can I force it to do this for a <form> submission?
EDIT: Here are some more details, as requested.
To create a resource, just POST multipart data to /resource-endpoint. In jQuery you might do something like
var data = new FormData();
data.append('property', 'value'); // Add payload values
$.ajax({
url: '/resource-endpoint'
type: 'POST',
cache: false,
contentType: false,
processData: false,
data: data
});
Doing it this way will create most resources, except for the "special" resource. Since AJAX requests cannot pass along cookies, and the request to create the "special" resource must include cookies, I have to mimic the website's UI more closely.
var id = 'some-id';
var iframe = $('<iframe name="' + id + '"></iframe>');
$(document.body).append(iframe);
var form = $('<form></form>');
form.attr({
target: id,
action: '/resource-endpoint,
method: 'POST',
enctype: 'multipart/form-data'
});
// Add payload values
form.append('<input name="property" value="value" />');
$(document.body).append(form);
form.submit();
This still sends along requests, but there appears to be something missing, because requests to create the "special" resource do not include cookies. I'm not sure how the native website javascript is doing this, as I can't find any difference between the forms that create regular resources and the form that creates "special" resources.
EDIT: Nevermind, I saw a native "special resource" POST request from the UI which doesn't pass along these cookies, so the secret must not be the cookies.

Can I use Apigee to make Facebook batch requests?

I'm trying to execute a Facebook batch request, as described in the docs from the Apigee API console. However, there doesn't seem to be an appropriate resource drop down for batch requests; it's trying to force me into selecting a specific resource, and then insists on a parameter in its "template" tab which is not what I want.
Are FB batch requests supported in the console?
It is possible, though the Facebook Console wasn't designed to make batch requests easy. You can try this:
Visit https://apigee.com/console/others
In the Resource box enter: https://graph.facebook.com
In the Query tab, create a parameter named "access_token" with the value of your facebook access token (because FB uses bearer tokens, you can cut and paste one from any valid OAuth request)
In the Body tab, enter the batch as a JSON string. Example below.
batch=[{"method": "GET", "relative_url": "me"},{"method": "GET", "relative_url": "me/friends?limit=50"}]
Hope that helps,
Marsh

Logging a user out when using HTTP Basic authentication

I want users to be able to log in via HTTP Basic authentication modes.
The problem is that I also want them to be able to log out again - weirdly browsers just don't seem to support that.
This is considered to be a social-hacking risk - user leaves their machine unlocked and their browser open and someone else can easily visit the site as them. Note that just closing the browser-tab is not enough to reset the token, so it could be an easy thing for users to miss.
So I've come up with a workaround, but it's a total cludge:
1) Redirect them to a Logoff page
2) On that page fire a script to ajax load another page with dummy credentials:
$j.ajax({
url: '<%:Url.Action("LogOff401", new { id = random })%>',
type: 'POST',
username: '<%:random%>',
password: '<%:random%>',
success: function () { alert('logged off'); }
});
3) That should always return 401 the first time (to force the new credentials to be passed) and then only accept the dummy credentials:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult LogOff401(string id)
{
// if we've been passed HTTP authorisation
string httpAuth = this.Request.Headers["Authorization"];
if (!string.IsNullOrEmpty(httpAuth) &&
httpAuth.StartsWith("basic", StringComparison.OrdinalIgnoreCase))
{
// build the string we expect - don't allow regular users to pass
byte[] enc = Encoding.UTF8.GetBytes(id + ':' + id);
string expected = "basic " + Convert.ToBase64String(enc);
if (string.Equals(httpAuth, expected, StringComparison.OrdinalIgnoreCase))
{
return Content("You are logged out.");
}
}
// return a request for an HTTP basic auth token, this will cause XmlHttp to pass the new header
this.Response.StatusCode = 401;
this.Response.StatusDescription = "Unauthorized";
this.Response.AppendHeader("WWW-Authenticate", "basic realm=\"My Realm\"");
return Content("Force AJAX component to sent header");
}
4) Now the random string credentials have been accepted and cached by the browser instead. When they visit another page it will try to use them, fail, and then prompt for the right ones.
Note that my code examples are using jQuery and ASP.Net MVC, but the same thing should be possible with any technology stack.
There's another way to do this in IE6 and above:
document.execCommand("ClearAuthenticationCache");
However that clears all authentication - they log out of my site and they're logged out of their e-mail too. So that's out.
Is there any better way to do this?
I've seen other questions on this, but they're 2 years old - is there any better way now in IE9, FX4, Chrome etc?
If there is no better way to do this can this cludge be relied upon? Is there any way to make it more robust?
The short anser is:
There is no reliable procedure for achieving a "logoff" using
HTTP Basic or Digest authentication given current implemenations of basic auth.
Such authentication works by having the client add an Authorization header
to the request.
If for a certain resource the server is not satisfied with the credentials provided (e.g. if there are none), it will responde with a
"401 Unauthorized" status code and request authentication. For that purpose it will provide a WWW-Authenticate header with the response.
A client need not wait for a server requesting authentication.
It may simply provide an Authorization header based on some local
assumptions (e.g. cached information from the last successful attempt).
While your outlined approach on "clearing" out authentication info has a good chance of working with a wide range of clients (namely widespread browsers),
there is absolutely no guarantee that a nother client might be "smarter" and
simply discriminate proper authentication data for your "logout" page and any other pages of the target site.
You will recognize a similar "problem" with using client side certificate based authentication.
As long as there is no explicit support from clients you might fight on lost ground.
So, if "logoff" is a concern, move over to any session based authentication.
If you have access to the implementation of authentication on the server side you might be able implementing a functionality that will disregard authentication information presented with Authorization header (if still identical to what has been presented during current "session) on request of your application level code (or provide some "timout" after which any credentials will be re-requested), so that the client will ask the user for providing "new" credentials (performing a new login).