Enhancement: Add extra resources for `util accesstoken get`

[milanholemans]

Currently when I want an accesstoken for Graph I have to run m365 util accesstoken get --resource https://graph.microsoft.com. For SharePoint I can just run m365 util accesstoken get --resource sharepoint. To me it would be useful if we add another named resource for Graph so you can use m365 util accesstoken get --resource graph to get a graph token.

Also noticed that we support sharepoint as resource value, but this isn't included in the docs. The only way to know this if you look at one of the examples. Therefore I also suggest that we also add these named resources to the description of the resource option in the docs.

Suggested resources to add:

Resource	Endpoint
graph	https://graph.microsoft.com

[nicodecleyre]

That's an excellent idea! Have you considered using tokens for the resource option similar to how we use them for the m365 request command? Specifically, utilizing the @graph and @spo tokens.

[milanholemans]

That's an excellent idea! Have you considered using tokens for the resource option similar to how we use them for the m365 request command? Specifically, utilizing the @graph and @spo tokens.

Yeah, I know that you can send requests using m365 request, but I'm more a Postman guy 😊 When trying to clear things out how a certain API endpoint works, Postman is way more convenient to toggle headers, parameters, edit JSON body, ... Also support syntax highlighting etc.

[nicodecleyre]

That's an excellent idea! Have you considered using tokens for the resource option similar to how we use them for the m365 request command? Specifically, utilizing the @graph and @spo tokens.

Yeah, I know that you can send requests using m365 request, but I'm more a Postman guy 😊 When trying to clear things out how a certain API endpoint works, Postman is way more convenient to toggle headers, parameters, edit JSON body, ... Also support syntax highlighting etc.

What I actually mean is using the tokens in this command, for example: m365 util accesstoken get --resource @graph

m365 util accesstoken get --resource @spo

[milanholemans]

What I actually mean is using the tokens in this command, for example: m365 util accesstoken get --resource @graph

m365 util accesstoken get --resource @spo

Aw ok. Well because we already support sharepoint as resource right now, I'm afraid that will be a breaking change.

[martinlingstuyl]

Yes, and I'm not sure what we would gain from that setup as opposed to the autocomplete values we currently have. I'd say, let's keep those.

[martinlingstuyl]

But I like the idea @milanholemans! Should we add autocomplete prefab values for all resources we currently expose? (PowerApps as well, for example)

[milanholemans]

But I like the idea @milanholemans! Should we add autocomplete prefab values for all resources we currently expose? (PowerApps as well, for example)

Was kinda thinking the same 🙂

[milanholemans]

But I like the idea @milanholemans! Should we add autocomplete prefab values for all resources we currently expose? (PowerApps as well, for example)

Updated the specs with some extra resources which I think are the most useful.

[waldekmastykarz]

Should it be o365management or m365management?

[waldekmastykarz]

Personally, I find powerapps and powerplatform not obvious. If you told me you've got this token and asked me which endpoints they use, I wouldn't be able to tell you. Not sure if it's different with folks who use these APIs more often, but I wonder if we're not going too far here. @appieschot, any experience you could share here?

[milanholemans]

Should it be o365management or m365management?

According to the docs and Azure, it's still called O365

If you told me you've got this token and asked me which endpoints they use, I wouldn't be able to tell you. Not sure if it's different with folks who use these APIs more often, but I wonder if we're not going too far here.

Yes while writing them down, I kinda had the same feeling tbh.

[martinlingstuyl]

We could add an explanatory section to the docs.. I'm sure that if you work with these endpoints, it's kind of easy to use it this way as soon as you know it. Plus it doesn't hinder other folks, as it's autocompleted anyway.

[appieschot]

Personally, I find powerapps and powerplatform not obvious. If you told me you've got this token and asked me which endpoints they use, I wouldn't be able to tell you. Not sure if it's different with folks who use these APIs more often, but I wonder if we're not going too far here. @appieschot, any experience you could share here?

Purely semantics I know the difference, working in a real life scenario I spend most time working with solutions that contains Power Automate and Power Apps, having to switch would take mental effort.

Sample: work with an app that does something on button press, might want to read some props on that specific action. Could be both inline in the App or a Power Automate process that gets fired.

I do like the idea however and wouldn't be surprised is we move more to a single PowerPlatform token 💡

[waldekmastykarz]

Purely semantics I know the difference, working in a real life scenario I spend most time working with solutions that contains Power Automate and Power Apps, having to switch would take mental effort.

In this case it's more the API to which these tokens maps. Is it obvious which one either of these tokens are mapped to?

[milanholemans]

If it's not clear enough we can remove the power platform and power apps resources. Actually I'm also in doubt that the o365 management API resource will be used.

[martinlingstuyl]

I'd say: just add every possible resource we use and show a table in the docs how these map to apis. Why not? But maybe I'm starting to repeat myself. :)

[milanholemans]

I'd say: just add every possible resource we use and show a table in the docs how these map to apis. Why not? But maybe I'm starting to repeat myself. :)

Also fine for me 😅

[waldekmastykarz]

I'd say: just add every possible resource we use and show a table in the docs how these map to apis. Why not?

Why should we? Just because we use an API, doesn't mean that folks will use it either. If we need a table of mappings between resources and tokens, do we make things easier or harder? I wouldn't add tokens just for the sake of adding them. I suggest that we start with those that we see being used the most and add more when the need arises.

[milanholemans]

I'd say: just add every possible resource we use and show a table in the docs how these map to apis. Why not?

Why should we? Just because we use an API, doesn't mean that folks will use it either. If we need a table of mappings between resources and tokens, do we make things easier or harder? I wouldn't add tokens just for the sake of adding them. I suggest that we start with those that we see being used the most and add more when the need arises.

I that case, we only add Graph as resource right? We could also add O365 management API endpoint, but according to me, this will never be used (used to fetch audit logs).

[waldekmastykarz]

I that case, we only add Graph as resource right? We could also add O365 management API endpoint, but according to me, this will never be used (used to fetch audit logs).

Correct, only Graph. In this case, I suggest we rely on user demand and wait until someone asks for other resources and can share a use case that we don't address with a specific command already.

[milanholemans]

Updated the specs, thank you!

[dojcsakj]

Can I work on this?

[milanholemans]

yes definitely @dojcsakj!

[dojcsakj]

Please, discard abeecd0 - sorry.