When using the Object Storage GE node.js connector implementation from https://github.com/arvidkahl/fiware-object-storage we encounter the problem "no tenants available". We tested with two different community accounts where we first set up an object container within the fiware cloud.
We are able to Receive an Auth Token and get a connection established message, but then we do not get the tenant ID i think. has anyone experienced something like that and can help or give us a better understanding of what is going wrong here?
we installed the fiware-object-storage with npm install fiware-object-storage.
this is our connection code:
var fiwareObjectStorageConfig = {
auth : conf.fiware.auth_url, // IP of the Auth Services, likely "cloud.lab.fi-ware.org"
url : conf.fiware.object_storage_url, // IP of the Object Storage GE -> "cloud.lab.fi-ware.org"
user : conf.fiware.user, // Your FIWARE account email
password : conf.fiware.password, // Your FIWARE account password.. i know.. no comment.
container : conf.fiware.container // Whatever container you want to connect to
};
var fiwareObjectStorage = require('fiware-object-storage');
fios = fiwareObjectStorage(fiwareObjectStorageConfig);
fios.connectToObjectStorage(function() {
console.log(fios.getFileList());
});
This library is a third party library and it is not an official FIWARE implementation.
As you said, there is a problem with this library. I have tested and it needs some fixes. I could not reproduce your error with my account but I have another one while getting file list.
The best option is waiting for their developers to improve that simple library like select Tenant in config file. By now it takes the first tenant on the list.
This is my config file to access Spain2 object store:
fiwareObjectStorageConfig = {
url : '172.32.0.144',
auth : 'cloud.lab.fi-ware.org',
container : 'myContainer',
user : "", // Your FIWARE account email
password : "" // Your FIWARE account password.
};
Related
I have an node application deployed in GCP.
The application includes code to access ressources in AWS-cloud.
For this purpose it uses the aws-SDK with ChainableTemporaryCredentials.
The relevant code lines are...
const credentials = new ChainableTemporaryCredentials({
params: {
RoleArn: `arn:aws:iam::${this.accountId}:role/${this.targetRoleName}`,
RoleSessionName: this.targetRoleName,
},
masterCredentials: new WebIdentityCredentials({
RoleArn: `arn:aws:iam::${this.proxyAccountId}:role/${this.proxyRoleName}`,
RoleSessionName: this.proxyRoleName,
WebIdentityToken: token,
}),
})
await credentials.getPromise()
The WebIdentityToken was received from google and looks good.
At AWS-side I created an proxy-role (the line from masterCredentials RoleArn).
However at runtime I get the error:
Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
I do not understand this error. Because my application runs in GCP and I use temporary credentials I do not understand why I should use aws-credentials in form of an credentials file or environment variables like AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY. I thought the idea to use ChainableTemporaryCredentials is NOT to have direct aws-credentials. Right?
You can see the public code at:
https://github.com/cloud-carbon-footprint/cloud-carbon-footprint/blob/trunk/packages/aws/src/application/GCPCredentials.ts
and documentation regarding env-variables at:
https://www.cloudcarbonfootprint.org/docs/configurations-glossary/
Any help which leads to understanding of this error message is welcome.
Thomas
Solved it. "Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1 was totally misleading." In reality it was a problem with the field-names in the GCP-JWT-token und the policy in aws. See https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_aud
I was able to connect and upload videos using the library but when I deleted the app connection on Vimeo.com (as a test) the app didn't authorize again.
the upload looks like it's working but nothing is uploaded as the app is no longer connected.
I deleted the app on the phone and restarted but it still won't re-authorize the app.
This comes up in the output:
Vimeo upload state : Executing
Vimeo upload state : Finished
Invalid http status code for download task.
And this is in OldVimeoUpload.swift: ( didn't include the actual access code!)
import Foundation
class OldVimeoUpload: VimeoUpload
{
static var VIMEO_ACCESS_TOKEN :String! // = "there's a string of numbers here"
static let sharedInstance = OldVimeoUpload(backgroundSessionIdentifier: "") { () -> String? in
return VIMEO_ACCESS_TOKEN // See README for details on how to obtain and OAuth token
}
// MARK: - Initialization
override init(backgroundSessionIdentifier: String, authTokenBlock: AuthTokenBlock)
{
super.init(backgroundSessionIdentifier: backgroundSessionIdentifier, authTokenBlock: authTokenBlock)
}
}
It looks like the access token number is commented out. I deleted the 2 forward slashes to see if that would fix it but it didn't.
I spoke too soon.
It sounds like you went to developer.vimeo.com and created an auth token. Used it to upload videos. And then went back to developer.vimeo.com and deleted the auth token.
The app / VimeoUpload will not automatically re-authenticated in this situation. You've killed the token and the app cannot request a new one for you. You'll need to create a new auth token and plug it into the app.
If this is not accurate and you're describing a different issue let us know.
If you inspect the error that's thrown from the failing request I'm guessing you'll see it's a 401 unauthorized related to using an invalid token.
Edit:
Disconnecting your app (as described in your comment below) has the same effect as deleting your auth token from developer.vimeo.com.
Also, VimeoUpload accepts a hardcoded auth token (as you see from the README and your code sample). It will not automatically re-authenticate, probably ever.
If you'd like to handle authentication in your app check out VimeoNetworking or VIMNetworking. Either of those libraries can be used to create a variety of authentication flows / scenarios. Still, if a logged in user disconnects or deletes their token, you will need them to deliberately re-authenticate (i.e. you will need to build that flow yourself). In that case, the user has explicitly stated that they don't want the app to be able to access information on their behalf. It would go against our security contract with them to automatically re-authenticate somehow.
Does that make sense?
I am trying to create user using smack client 4.1.2. I am getting below error.
Send XML on stream = <<"<iq from='abc.example.com' to='admin#abc.example.com/Smack' id='Dym8b-14' type='error'><query xmlns=jabber:iq:register><password>xxxxxx</password><username>user</username><registered/></query><error code=403 type=auth><forbidden xmlns=urn:ietf:params:xml:ns:xmpp-stanzas/></error></iq>">>
My ejabberd config looks like below (.yml file)
register_from:
admin: allow
...
access_from: register_from
access: register
I am still getting above error. Please help
Adding code snippet to show how I create new user using smack 4.1.0
connection = new XMPPTCPConnection(getConnectionConfiguration());
connection.connect();
connection.login("admin", "admin");
if(connection.isAuthenticated())
{
AccountManager accountManager = AccountManager.getInstance(connection);
accountManager.sensitiveOperationOverInsecureConnection(true);
accountManager.createAccount(userName, password);
connection.disconnect();
// The account has been created, so we can now login
connection.login(userName, password);
}
private XMPPTCPConnectionConfiguration getConnectionConfiguration()
{
XMPPTCPConnectionConfiguration config = XMPPTCPConnectionConfiguration.builder()
.setServiceName("abc.example.com")
.setHost("abc.example.com")
.setPort(5222)
.build();
return config;
}
I found the issue. It was due to trusted_network tag had value as loopback:allow in ejabberd config file. I changed it to all:allow. It started working.
The snippet of configuration you provide is too small and badly indented, so it is impossible to tell you what is wrong in your configuration.
However, considering your config is correct, you should check that your user is properly authenticated with the right ACL credentials before sending the register request. Most client libraries assume self user registration and try to send the register before doing any form of authentication.
The question pertains to the level of integration of Wirecloud into IDM and Object Storage, when it comes to getting access to shared Containers. Specifically, from a private WC instance running on FI-LAB and having integrated with FI-LAB IDM using the url http://cloud.lab.fi-ware.org/keystone/v2.0 as a keystone endpoint, I seem to be unable to retrieve all the available tenants from IDM (i just get a single one, being the user logged into from WC - say TENANT-B):
{"tenants":[{"enabled":true,"id":"0000000000000000000000000000EFGH","name":"TENANT-B"}]}
Of course, i can see that when logging into FI-LAB from the portal, the answer i get when calling http://cloud.lab.fi-ware.org/keystone/v2.0/tenants is correct:
{"tenants":[{"enabled":true,"id":"0000000000000000000000000000ABCD","name":"TENANT-A"},{"enabled":true,"id":"0000000000000000000000000000EFGH","name":"TENANT-B"}]}
I am trying to get the tenants using the keystone.getTenant({... options ...}) call:
keystone = new KeystoneAPI(keystone_url, {
use_user_fiware_token : true
});
keystone.getTenants({
onSuccess : onGetTenants,
onFailure : function() {
alert("Could not get a valid tenant list");
}
});
Is multitenancy not supported natively on WC or am I missing something?
Seems to be working now, take into account that the IdM and the Open Stack integration has changed.
I am trying to transfer ownership of files to Super Administrator. The essential part of the code is shown below. The same code works if I transfer ownership of a document that I own. But in this case the original owner is another user in the same domain. [EDIT] I know there is a "transfer-ownership-of-files-from-1-user-to-another" in admin panel, but this is needed for a case when multiple files/folders, from multiple owners needs to be transferred programmatically. [/EDIT]
So the simple scenario is:
user#domain.com owns a file
the ownership needs to be transferred to the admin#domain.com (Super Administrator). The code is running in AppEngine in Java Servlet. And the Super Administrator is authenticated with OAuth.
However it throws (500 OK) exception always in line update.execute(); (showed in the end).
Is this operation impossible even for a Super Admin?
Thanks for any tips!
try {
Drive service = getDriveService();
Permission newPerm = new Permission();
newPerm.setValue("admin#domain.com");
newPerm.setType("user");
newPerm.setRole("writer");
newPerm = service.permissions().insert(fileId, newPerm).execute();
newPerm.setRole("owner");
Update update = service.permissions().update(fileId, newPerm.getId(), newPerm);
update.setTransferOwnership(true);
update.execute();
} catch (IOException e) {
e.printStackTrace();
log.severe(e.getMessage());
}
The exception thrown looks like:
SEVERE: 500 OK
{
"code" : 500,
"errors" : [ {
"domain" : "global",
"message" : "Internal Error",
"reason" : "internalError"
} ],
"message" : "Internal Error"
}
I finally got this working at least partly. Thanks #ZigMandel for the "impersonation" hint! Now I followed this Domain-wide Delegation of Authority carefully. And used the GoogleCredential created using "Service account"-key. With this credential I can impersonate the Drive API operations like adding permissions and transferring ownership to Admin, for example.
The problem that still remains is that with current Drive API it is impossible to programmatically determine the owner email address, which is needed for impersonated credential creation. Now I need to find a workaround for this. Anyway the fundamental idea works now. Thanks!
You wont be able to do it from apps script.
Can be done from appengine. Ive done it but its beyond of the scope to explain here. Involves using the drive api on behalf of the file owner and adding the oauth permissions at the domain level.