Hi Alex, The current implementation returns `2` as exit code when the login fails or you try make a query and the authentication failed.
Juan On Thu, 23 May 2019 at 12:09, Alex Heneveld <[email protected]> wrote: > > Juan- > > This looks really good to me. > > If you don't use OAuth, no change, and `br` works as it always has. > > If you do need OAuth, you define the process to get the header (maybe > another script, say br-my-oauth), which can then use`br` to persist the > header for subsequent usage by `br`. You'll have to explicitly > re-generate the header whenever the session times out. > > Alternatively the user could rename `br` to `br-original` then write > their own script `br` which tries `br-original` but if auth fails it > automaticalllly invokes `br-my-oauth` and retries `br-original`. That > way login would be as seamless as possible. > > Can we make it so `br` returns a special non-zero exit code on auth > faillure? (Different to exit code on other errors.) > > Best > Alex > > > On 23/05/2019 10:33, Juan Cabrerizo wrote: > > Hi Geoff. Thanks your your thoughts. > > > > As different oauth providers can implement login in very different ways, > > for the moment I'm bypassing the process for request the token. Once the > > user get it with an external mechanism, he can add it when do login with > br. > > As you said, once you use the token for login, you need sent it on all > REST > > calls for authentication. > > And also, I added a new parameter for do not request for user and > password. > > If it is added, br won't sent the current basic authentication header. > > The command will be executed as: > > > > br login http://server:port --noCredentials --header 'Authorization: > Bearer > > xxxxx.yyyyyy.zzzzz' --header 'OtherHeader=headerValue' > > > > This execution will crate this persisted yaml: > > { > > "credentials": { > > "http://localhost:8081": "Og==" > > }, > > "credentialsRequired": false, > > "headers": { > > "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "", > > "OtherHeader": "headerValue" > > }, > > "skipSslChecks": false, > > "target": "http://localhost:8081"; > > } > > > > If you don't add this new parameter, the behavior will be the same as > > before, so it won't affect that not use oauth. > > I defined for the moment `headers` and `credentialsRequired` as global > (no > > related to any target) as is for `skipSslChecks` > > > > Other more ambitious change could be modify the structure to something > like: > > { > > "servers": { > > "http://localhost:8081":{ > > > > "credentials":"Odddg==" > > > > }, > > http://remote1:8081":{ > > > > "credentials":"xxxxx==" > > > > }, > > http://remote2:8081":{ > > > > "credentialsRequired": false, > > > > "headers": { > > > > "Authorization: Bearer xxxxx.yyyyyy.zzzzz": "", > > > > "OtherHeader": "headerValue" > > > > }, > > > > }, > > > > }, > > > > "skipSslChecks": false, > > "target": "http://localhost:8081"; > > } > > > > I already have the first version working and i'm testing it in a couple > of > > environments, probably I'c create a PR this week. I'm not sure if it > worth > > make more changes. > > > > Thanks again for your ideas. > > > > Regards > > > > Juan > > > > On Wed, 22 May 2019 at 23:12, Geoff Macartney <[email protected] > > > > wrote: > > > >> Hi Juan, > >> > >> If I understand you right you mean that the login command will do a > >> request to Brooklyn, sending the username and collected password, and > >> Brooklyn will do the interaction with the OAuth server to obtain a > token, > >> which it will return to the br tool (in the form of a JWT token). Then > br > >> can store that in its local .brooklyn_cli file. What is the REST > request > >> to be used for that login action? > >> > >> Subsequently all requests will be sent with > >> > >> Authorization: Bearer xxxxx.yyyyyy.zzzzz > >> > >> Where x.y.z is the JWT token. > >> > >> Is the above understanding right? > >> > >> How will your design support br being able to log in to some Brooklyn > >> servers without OAuth configured, and others that do use OAuth? > >> > >> Just a couple of thoughts, but I’m keen to see this. Happy to review any > >> early draft pull requests you may have. > >> > >> Regards > >> Geoff > >> > >>> On 21 May 2019, at 15:11, Juan Cabrerizo <[email protected]> wrote: > >>> > >>> Hello all > >>> > >>> I'm continuing with changes for allow oauth authentication in Apache > >>> Brooklyn. I'm working now on the BR command line tool. > >>> The initial idea is send the JWT access token in the headers instead > send > >>> the basic authentication header when the token is available after > >> execute a > >>> login command to get the token. > >>> > >>> I'll modify the BR login command to allow inject headers and store it > on > >>> the yaml file and sent on the API calls. Is a new Authorization header > is > >>> available sent it rather than the default authentication. > >>> > >>> Any concerns about this approach? I'm fully open to any idea. > >>> > >>> Best regards. > >>> > >>> Juan > >>> > >>> -- > >>> Juan Cabrerizo > >>> Software Engineer > >>> > >>> *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud > >>> E: [email protected] > >>> L: https://www.linkedin.com/in/juancabrerizo/ > >>> > >>> Need a hand with AWS? Get a Free Consultation. > >> > > -- Juan Cabrerizo Software Engineer *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud E: [email protected] L: https://www.linkedin.com/in/juancabrerizo/ Need a hand with AWS? Get a Free Consultation.
