Atomic bare-bones API examples, a little help please

Hi all, I’m wondering if I can get some help getting started with the APIs and have some questions.
I’m using MockRoutingPack and SafeBrowser.

For example, window.safeAuth.authorise(app) works fine in some examples I’ve run up, but this doesn’t really assist my understanding. The thing is, I can’t relate this syntax to the API docs at https://api.safedev.org/auth/authorize-app.html.
Are we talking the same API? Are there intermediate dependencies somewhere?

While I’m not strong in javascript having come from mostly server-side web app dev, I can usually find my way around, and haven’t had trouble in the past coding to rest APIs, so some help getting started would be greatly appreciated. In particular, I’d love just a couple of super-simple atomic examples with the minimum of dependencies that align with the published API.

So, question. With zero app, simple safe, etc, is the call being made directly to the launcher? Also, in any given context, how to I derive a URL for an API call? It’s confusing to me trying to think about ‘where’ the API is in order to address it, given the fact that there is no server, I’m assuming it’s a path that is understood on the local machine to the Launcher?

Thanks to those who have worked up the examples available so far. If someone can help me over this first little hump, I’d like to create a doc to go from absolute zero to the examples currently available, with an explanation of what is actually happening on an API call. If all goes well I can present this at the SafeNetwork Meetup here in Melbourne next month.

Cheers

Peter

7 Likes

+1
I think this is high on many people’s ‘most wanted’ list

4 Likes

As the launcher disappear, the API with authenticator will be quite different. This is the last documentation of the new API:

4 Likes

Hi, thank you digipl. Now, the launcher will disappear? This will not be the gateway to the safenetwork?

So, with the js examples, there is a dependency, which is the beaker-plugin-safe-app? This makes some sense now as far as the examples I was trying to understand are concerned. So does this plugin, in turn, make calls against the documented API?

2 Likes

I hope so, feeling rather dumb at the moment :confused::slight_smile:

Yes, I think we have to get going with this and provide a pathway for general web devs to pick up and start running. There are so many out there comfortable with the web stack and I’ve been wanting to be able to present something specific in the way of, “here’s how you do it”, but with the rate of change, it’s hard to come up with a good workflow for early app development. I’m most interested in a frame-work agnostic approach and find the trend for bundling a whole stack of dependencies into examples that ultimately just need to show something really straight-forward quite a barrier. I don’t want to run a git client every time I want to test something and I don’t want to use npm all the time just because it’s there.

I am finding MockRoutingPack a real boon, and with this and SafeBrowser, I’ve got a good, solid environment for testing and developing.

So, if I can get some support, I’d like to make a start on a cookbook style wiki or something that isolates and clearly explains each of the fundamental calls a coder may wish to make on the API.

Cheers

Peter

3 Likes

Right. If memory serves me (apologies if it isn’t the right episode), I think it was explained on this podcast: https://letstalkbitcoin.com/blog/post/safe-crossroads-podcast-35-viv-rajkumar-cto-maidsafe

1 Like

Can anyone direct me to any discussions or clarifications on safe_app_nodejs and beaker-plugin-safe-app? What are the motivations? Why is nodejs being used in what is essentially a clien-side environment?

1 Like

Authenticator is also mentioned briefly in Nick’s summary https://blog.maidsafe.net/tag/authenticator/

1 Like

Yes, found it thank you, at about 50:40 (https://letstalkbitcoin.com/blog/post/safe-crossroads-podcast-35-viv-rajkumar-cto-maidsafe). So, in the future no mediator at a device/computer level, each app to authenticate and mediate permissions directly, is that the gist?

1 Like

Ah, that’s very helpful indeed, now it’s all starting to make sense.

“The process of converting our APIs away from a REST paradigm to SDKs was essential to cater for mobile devices, as the requirement for REST APIs to maintain state would not have worked with mobile devices that disconnect and reconnect regularly. Users of the SAFE Network will gain access through the Authenticator, a secure gateway that protects user credentials from the application itself. The Authenticator is currently being bundled with the SAFE browser and will enable users to securely authenticate themselves onto the network, or enable them to browse publicly available data without logging in.” (https://blog.maidsafe.net/tag/authenticator/)

I approve of the idea that the network shouldn’t need to carry client state, but I didn’t think the choice of a rest api implies statefulness.

P

2 Likes

The rest API previously managed user state, but I see no reason why a new version couldn’t be implemented, with this abstracted away to the network.

I am just happy that the authentication and authorisation is going to be done at the network level going forward. This is a much more robust from a security perspective.

1 Like

The information about new implementation are in the different RFC. For the new Authentication Flow you can read:

You can find more information in the appendixes:

1 Like

Thank you, I’ll do some reading, that’s very helpful.

I’ve had a (preliminary only) read of this. It seems like a pretty big departure from the ‘state machine’ idea of forcing all network requests through a single point (Launcher). I don’t yet understand the full implications of this, but in broad terms, it’s each application for itself as far as authenticating to the network, correct?

A couple of quick questions:
Q1. Does this impact the security model significantly, ie, is this approach as secure?
Q2. Does this impact the ‘single sign on’ aspect of SafeNetwork?

… or, have I completely misunderstood so far?

Many thanks

Peter

1 Like

The Q2 answer is not. The single sign on remains.

The user give permission to Apps to mutate data on behalf of the owner. Without this permission the Apps can do noting because all try to mutate will be stopped by the Maid-Managers.
The owner can revoke this permission in any moment. In this case all data is reencrypted with a new key to be not readable by the revoked App.

1 Like

Thank you for the reply. So, is there continual recurrent dialog from the app requesting data access or is this once at the beginning of each session? In the latter case , we have to permission each app we use for each session, is that correct?

Cheers

P

Not a dialog but a path. All Apps required mutation go via Maid-Manager. If the sign::PublicKey send by the App are in the allowed list the Maid-Managers will then forward the request to the appropriate Data-Managers. If not the request is blocked.
The user can revoke permission in any moment.

2 Likes

This topic was automatically closed after 60 days. New replies are no longer allowed.