Consistent timeouts for fetching initial /start/ page. about aws-sso HOT 14 CLOSED

Confirmed your last theory, removed the implicit wait in ssodriver.py and boosted the explicit wait timeouts in the _*_element_by_id invocations and yeah, it's working now.

from aws-sso.

Hi @so0k, this tool is specific to the AWS service "AWS SSO" ; not for generic IdP like ADFS. Unfortunately using Chrome is the simplest way I found to interact with the service as it is using GWT for auth and it looks like a nightmare to play with (especially in Python) (https://srcincite.io/blog/2017/04/27/from-serialized-to-shell-auditing-google-web-toolkit.html)

People have been asking for API/CLI support for a long time now (aws/aws-cli#3447) but, as always, no ETA or comments on this.

from aws-sso.

Sometimes you eat the bear, sometimes the bear eats you.

Cheers for the support with this mate, thanks for the contributions to the community.

from aws-sso.

By the way, to clarify, I've been unable to actually use the tool because of this, I've also attempted altering the timeout limits myself, to 20 seconds in every case, and it's had no effect, so I assume I'm making a mistake somewhere in my edits.

from aws-sso.

I'm using both implicit and explicit waits so that may be because of that. I'll take this into account for the next update. I hope I can make progress on that very soon. Thanks for the feedback 👍

from aws-sso.

What's your opinion on the waits? Do you think the implicit or explicits are more important? IMO I'd rather the implicit seeing as if it finds before with the polling, you still get the best result, explicit waits create a linear effect on execution performance. Asking because if it's not gonna get too crazy I may just PR it myself.

from aws-sso.

It's a tricky topic, currently the only way we have to check for success/error is to check for the presence of elements in the DOM (e.g. portal, asking for mfa or alert message). Most of the time after configuration we won't face password errors or MFA prompts in order to get a fresh token so I guess checking for the portal page should be prioritized but having "long" timeouts can be painful while configuring a new profile. I guess we need to find a tradeoff.

Base timeout should definitely be configurable to deal with edge cases anyway.

Ideal solution would be to be able to find all three possible elements in a single find/wait and act on whichever is found first but I didn't find how to that with Selenium.. 😕

I'm working on a refactor in https://github.com/wnkz/aws-sso/tree/ft/lots-of-things and SSODriver is next. You're welcome to have a look at it ;)

from aws-sso.

same issue I was facing, increasing the timeouts helped...

Also had to pass in the region explicitly

is there no AWS API to work with SSO at all? I guess the idea is to layer an IdP on top and use something like https://github.com/allcloud-io/clisso ... (we were having a look at okta, but it hasn't been rolled out yet) - your tool helps me preserve my sanity, thank you for making it available!

from aws-sso.

sure, your tool seems the perfect stop gap until we roll out okta, at which point we will most likely switch to allcloud-io/clisso

from aws-sso.

from aws-sso.

This looks oddly familiar 🙃

from aws-sso.

@JohnVonNeumann in the end, it's way better that AWS support this themselves. I've had a look at the code, they added stuff down to botocore itself. Seeing them implement this almost like it I did is comforting at least ;)

from aws-sso.

from aws-sso.

Alright, well, thanks for the memories. Peace.

from aws-sso.