Either there's something borked in my environment or this functionality is broken. It appears it worked at one point according to the blog I followed:
What I'd like to do is run my script, enter the MFA. Then be able to run it again without entering MFA making use of cached session token.
The samples I've seen are:
session = boto3.Session(profile_name='w2-cf3')
ec2_client = session.client('ec2',region_name='us-west-2')
I'm then prompted for my mfa:
Enter MFA code:
I enter it and my code runs. At this point, my session token should be cached, that's how it works in awscli. However, on the second run, instead of reading in my cached session for this profile, boto3 disregards and prompts me again for my MFA:
Enter MFA code:
Here's what my ~/.aws/config file looks like:
[profile default]
region = us-west-2
output = json
[profile w2-cf3]
region = us-west-2
source_profile = default
role_arn = arn:aws:iam::<accountid>:role/<role>
mfa_serial = arn:aws:iam::<accountid>:mfa/<user>
Here's what my ~/.aws/credentials file looks like:
[default]
aws_access_key_id=<access key>
aws_secret_access_key=<secret key>
Expected: I expected the second time I run my script is would make use of the cached session token like it does in awscli. The session token provided by AWS lasts 1 hour.
This is discussed in the GitHub repo for botocore here and a pull request has been submitted too and being discussed.
You're correct, this seems it was working back in 2014 but has been somehow removed, from the discussion on the thread mentioned above, this should be re-implemented soon, follow the pull request thread and make sure to upgrade when it is being release.
Related
I am trying to connect my Soffid 3 server with our custom web application named Schrift. I am using а JSON REST Web Services Connector for this purpose. I added REST Web service plugin and then configured an agent with JSON/XML/SOAP Rest webservice type.
Loading of objects is working fine. My REST connector connects to the web service successfully and gets data of the accounts.
The problem is when I am trying to update some data (for example, I am trying to lock an account), nothing happens. And unfortunately I don't know what should be happening. When should REST connector send updated data to the managed system and in which way? I didn't find any log entries saying that REST connector was trying to update an object on managed system. Maybe I did smth wrong or missed something.
I would appreciate for any help. I can post any conf or log details if you need.
Update#1
(I did some investigation after the first answer)
I checked the agent settings: Read only and Manual account creation are set to no
The account was set to unmanaged type, but I succeeded in changing its type to shared and then to single without getting an error. Now it is set to single
The task queue is empty.
Also I've checked that update method is present and update properties are set correctly. updateParams is not set (it means that all attributes should be sent to the managed system).
But when I change status of the account (from Enable to Disable), nothing happens.
In the console log I can see only these lines
14-Sep-2021 13:26:29.708 INFO [BPM-Scheduler:192.168.7.121:1] com.soffid.iam.bpm.job.JobExecutorThread.run No job to execute
When I manually run the task Analize impact for changes on Schrift, Execution log shows
Changes detected for accounts
=============================
NO CHANGE DETECTED
Changes detected for roles
=============================
NO CHANGE DETECTED
Update#2
After many attempts I made some progress. Now when I make some changes in the account, the task named UpdateAccount baklykov#irf.com.ua#Schrift appears, but runs with an error.
At first it was 415 Unsupported Media Type error as I wrote in comments, but now it looks a little different
Throws exception updating object : Extensible object [type = account]
EmployeeEmail: baklykov#irf.com.ua
IsLockedOut: true (log truncated) ...
caused by Unexpected response, Content-Type: null
Update#3
I found out that soffid's request for updating the object was in improper format (all the parameters were passed in the html request instead of putting them in json body)
After researching I found a method's property called Encoding and set it to application/json value.
Now the parameters are passed in json body (that's what I need), but now the problem is that soffid puts all the parameters in json body, including the key parameter by which the object for updating should be determined. My guess this is the reason why the object in the target system is still not updated.
In other words my application expects a request like this:
https://myapp.mysite.com/api/v1/Soffid/Employees?EmployeeEmail=baklykov%40irf.com.ua :
{"EmployeeLastName":"Baklykov","EmployeeFirstName":"Ivan"}
but Soffid sends this:
https://myapp.mysite.com/api/v1/Soffid/Employees:
{"EmployeeLastName":"Baklykov","EmployeeFirstName":"Ivan","EmployeeEmail":"baklykov#irf.com.ua"}
The system should have created a UpdateAccount task in the task queue. Please, verify:
The task engine is in automatic mode. In read-only or manual mode, no task will be created.
If you are updating an account, check the account is not set as unmanaged. In that case, no tasks is created.
Finally, verify the task queue has not held the task up.
Have you checked the engine mode? Look at Main Menu > Administration > Configure Soffid > Integration engine > Smart engine settings
It should be set to automatic.
Today I upgraded my Postman to the latest version, going from PostmanCanary 7.37.0-canary01 to 8.0.0-canary01.
I used to run a login request and save the returned access token to my environment variables with this script:
response = JSON.parse(responseBody);
access_token = response.access_token;
postman.setEnvironmentVariable("access_token",access_token);
to process this response :
{
"token_type": "Bearer",
"expires_in": "3599",
"ext_expires_in": "3599",
"expires_on": "1610147694",
"not_before": "1610143794",
"resource": "https://xxxxxxxxxxx.crm.dynamics.com/",
"access_token": "eyJ0eXAiOiJKV1QxxxxxxxxxxxxxxxI1NiIsIng1dCI6IjVPZjlQNUY5xxxxxxxxxxxxxxxxxxxxxx1EayIsxxxxZCI6IjxxxxxxxxxxxxNDd0NtxxxxxxxxxEREUS1Exxxx.xxxxxxxxxxxxxxxwczovL2RxxxxkZXZxxxxxxxxxxxxxxxxxxxxxcy5jb20vIiwiaXNxxxxxxxxxxxxxxxxzdHMud2luZG93cy5uZXQvNTBmOGZjYzxxxxxxxxxxxxxxxxxxxxxtMzZlZDU3YzdjOGEyLyIsImlhdCI6MTYxMDE0Mzc5NCwibmJmIjoxNjEwMTQzNzk0LCJleHAiOjE2MTAxNDc2OTQsImFpbyI6IkUySmdZQWc0bjN2L1o4VE5HT20zdnRQMStMZGFBZ0E9IiwiYXBwaWQiOiI4ZTc3ZDkzZi05MmY1LTRhMWYtOWY1OS1iZGY4ZGNkYTNkY2IiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC81MGY4ZmNjNC05NGQ4LTRmMDctODRlYi0zNmVkNTdjN2M4YTIvIiwib2lkIjoiYmJmZjA5OTQtZGQyNi00Nzg5LThlMjktMTc5OTIwOWI0ZDMxIiwicmgiOiIwLkFBQUF4UHo0VU5pVUIwLUU2emJ0VjhmSW9qX1pkNDcxa2g5S24xbTktTnphUGNzTkFCdy4iLCJzdWIiOiJiYmZmMDk5NC1kZDI2LTQ3ODktOGUyOS0xNzk5MjA5YjRkMzEiLCJ0aWQiOiI1MGY4ZmNjNC05NGQ4LTRmMDctODRlYi0zNmVkNTdjN2M4YTIiLCJ1dGkiOiJjZXJzaGlldGxFeU15Q1c2MVFWTUFBIiwidmVyIjoiMS4wIn0.EXV9P_DZIdVbTUK4PY6VcyrUmUx752ZA9MGr5BJ7xxxxxxxxxxxx-xxxxxxxxxX5wgidfGfoNklllZuoJVTi91jtnKP2T9Q-XFShpXhexDdCgOvMe9ZOOd0vOb11of1YPl37GKILtHikT3oPvKfUjBhOjZkFJo6F7pKeuxa3XiD_3WM1eCurVzuaG9iME94mFXb3HNTgUrWw9mPEqDwVzfxxxxx-xxxx-xxxxy0lw-2EcqpEYk7fqHUOTPUfAj2426zVV7ITfFPLdN08c4OND336sXpKjEFa5c7Buyk1dc24nawqJwCoKve1DaZAwPwljZKhGIIW4rd-1nitik2xWg"
}
Even if the environment variables did not exist prior to the call, this script would create them and set values. If I opened the environment variables, it would be listed.
After the upgrade, this no longer works. My subsequent requests kept failing because an old access_token was still there as it was not getting updated. I deleted the old access_token and confirmed that the access_token is now no longer being created.
I read about the resulting parsed JSON causing issues for other people because it is not text. I don't truly believe this to be the issue, mine is a single value, not a structure nor an array, but decided to play it safe and stringify it. Following the current documentation, I changed my script to :
response = JSON.parse(responseBody);
access_token = response.access_token;
console.log (access_token); // I can see the token in the console - parsing executed correctly
pm.environment.set("access_token",JSON.stringify(access_token)); // setting the environment variable
console.log(pm.environment.get("access_token")); // getting the exact same environment variable I have just set - I can see this on the console as well
console.log("WTF?!?!?"); // Self explanatory - added at the end to ensure all instructions in the script are read and executed - I see this every time as well
This does not work either (with or without stringify) and gives me the same results. Everything seems fine on the console, but when I look at my environment variables, access_token is not present although I can access it during the execution of the test script. Afterward, it is gone.
At this point I'm frustrated and at a loss - have anyone else seen similar behavior or am I missing something stupidly simple?
Hi Please use stable postman version :
https://www.postman.com/downloads/
Canary builds usually for beta testing , the issue seems to be there and i have raised a bug:https://github.com/postmanlabs/postman-app-support/issues/9412
Update The issue is fixed now : https://github.com/postmanlabs/postman-app-support/issues/9412
I am using tessera for execute private transaction's in Quorum. When invoking the third party (privateURL) API from the postman, I am getting the expected output but when calling the same API's from the other server I am getting an empty response with 200 status code( http://:9081/storeraw). This issue is happening due to the CORS. I've checked with:
File:///< HTML_PATH >
and it's working.
How to enable CORS for tessera third party API's?
Currently, this feature is not implemented in tessera. I'm working already I'll get back to you once it's done. For enabling CORS follow steps below.
Clone repository from git.
open the file /jaxrs-service/src/main/java/com/quorum/tessera/thridparty/RawTransactionResource.java
Replace
return Response.status(Status.OK)
.type(APPLICATION_JSON)
.entity(response)
.build();
with
return Response.status(Status.OK)
.type(APPLICATION_JSON)
.header("Access-Control-Allow-Origin", "*")
.entity(response)
.build();
Recompile the code
Start tessera.
Note: This will allow all origins, please modify the code as per your security needs. This is not a standard, I am working on config changes that will allow you to have the freedom to enable CORS with corresponding changes.
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 know how to insert a new group via MySQL, and it works, to a degree. The problem is that the database changes are not loaded into memory if you insert the group manually. Sending a HUP signal to the process does work, but it is kludgy and a hack. I desire elegance :)
What I am looking to do, if possible is to make changes (additions/deletions/changes) to a group via MySQL, and then send an HTTP request to the openfire server to read the new changes. Or in the alternative, add/delete/modify groups similar to how the User Service works.
If anyone can help I would appreciate it.
It seems to me that if sending a HUP signal works for you, then that's actually quite a simple, elegant and efficient way to get Openfire to read your new group, particularly if you do it with the following command on the Openfire server (and assuming it's running a Linux/Unix OS):
pkill -f -HUP openfire
If you still want to send an HTTP request to prompt Openfire to re-read the groups, the following Python script should do the job. It is targeted at Openfire 3.8.2, and depends on Python's mechanize library, which in Ubuntu is installed with the python-mechanize package. The script logs into the Openfire server, pulls up the Cache Summary page, selects the Group and Group Metadata Cache options, enables the submit button and then submits the form to clear those two caches.
#!/usr/bin/python
import mechanize
import cookielib
# Customize to suit your setup
of_host = 'http://openfire.server:9090'
of_user = 'admin_username'
of_pass = 'admin_password'
# Initialize browser and cookie jar
br = mechanize.Browser()
br.set_cookiejar(cookielib.LWPCookieJar())
# Log into Openfire server
br.open(of_host + '/login.jsp')
br.select_form('loginForm')
br.form['username'] = of_user
br.form['password'] = of_pass
br.submit()
# Select which cache items to clear in the Cache Summary page
# On my server, 13 is Group and 14 is Group Metadata Cache
br.open(of_host + '/system-cache.jsp')
br.select_form('cacheForm')
br.form['cacheID'] = ['13','14']
# Activate the submit button and submit the form
c = br.form.find_control('clear')
c.readonly = False
c.disabled = False
r = br.submit()
# Uncomment the following line if you want to view results
#print r.read()