Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Expose client API in safe_app only partially

Description

It should not be possible to create safe_core::Client with user's credentials directly through an app written in Rust (or at least it should not be as simple as it is now).

Move the Client constructors out of the Client impl so that they are stand-alone functions in the client module. Note that the client module is private and these functions will need to be pub use from lib.rs. Rename them when exporting by prepending a client_* prefix, i.e. unregistered should be pub use as client_unregistered. Do not re-export them in safe_app; only re-export Client. This ensures that the Client constructors are only usable within the safe_app internal implementation (unless somoene links directly to safe_core, in which case they're on their own).

We will be moving the following functions out of Client:

  • unregistered

  • registered_with_seed

  • registered

  • login_with_seed

  • login

  • from_keys

  • from_keys_with_hook

In addition to the new constructor-less Client, re-export the following:

  • ClientKeys and MDataInfo structs

  • DIR_TAG and MAIDSAFE_TAG constants

  • app_container_name function

  • immutable_data module

  • ipc module

  • mdata_info module

  • nfs module

Environment

None

Gliffy Diagrams

Activity

Nikita Baksalyar June 25, 2018 at 3:33 PM

The task is marked "Obsolete" now because the approach described in this task was deemed incorrect and having lots of disadvantages - for example, the *safe_core::Client* API would still be tightly coupled with *safe_app* and *safe_authenticator*, having public methods that are not used by *safe_app* directly.

Instead, the proposed solution is to get rid of the internal *safe_core::ClientType* struct and decouple *Client* from the Authenticator and Safe App APIs. The details of this better approach is still being fleshed out, so we close this task for now and we'll update it with a link to the new JIRA task once it's detailed.

Nikita Baksalyar June 25, 2018 at 12:14 PM

Updated the end date: it takes more time to complete/review it because we're trying several approaches to solve this. The current proposed solution (in the linked PR) has some disadvantages and we want to have a better implementation.

Nikita Baksalyar June 25, 2018 at 12:12 PM

Task moved via biggantt in program 'Client Libs'.
Details: Task synchronization

Marcin Swieczkowski June 18, 2018 at 8:54 PM

Task synchronization
Details: Task synchronization

Spandan Sharma June 7, 2018 at 9:54 AM

moving it back to backlog as the description needs more clarity/planning to put into TODO. to follow up

Unresolved

Details

Assignee

Reporter

Start date

End date

Story Points

Components

Priority

Parent

Created May 29, 2018 at 11:31 AM
Updated June 26, 2018 at 3:39 PM