Dropbox API and Datastore - Available across an Organisation? - dropbox

I have developed a localhost app using the dropbox datastore javascript api and it works well.
I didn't give any consideration before, but I presumed the data would be available to other users in the organisation. When other users access the app, that proves not to be the case. Can this be achieved or am I doing something completely wrong?
thanks

Although sharing is something we intend to add later, it's not available for datastores now. Every datastore is owned by a user and is only visible to that user.

Related

How to authenticate multiple api using Nuxt and nuxt-auth module

I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.

Disable popup when work with Shared Web Credentials (work directly)

Is there any way to work with data in shared web credentials directly, like with keychain, without showing popups on SecAddSharedWebCredential and SecRequestSharedWebCredential?
Or are there any other methods to work with it?
I want to share some data (string) between apps with different development teams.
I will recommend you to use the KeychainAccess which is a simple swift wrapper. And using Keychain is the best way to store small pieces of data that are critical to your app, like secrets and passwords.
Also the tutorial from raywenderlich would help you use the Keychain Services API.
App groups can be an option for your use case. Read below the apple API documentation and medium post
App Groups
Use a shared app group to share data/files between two/more apps or containing apps. An app group creates a secure container that multiple processes can access. Normally, each process runs in its own sandbox environment, but an app group lets both processes share a common directory.
Apple API docs - https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_application-groups
https://medium.com/#dinesh.kachhot/different-ways-to-share-data-between-apps-de75a0a46d4a
Also here is another stackoverflow post answering similar question - Communicating and persisting data between apps with App Groups

For Dropbox API is there a way to pull a list of users and see if MFA is enabled?

I am wanting to pull all users in my company dropbox and then check to see if their accounts have MFA enabled. I read over the documentation for Dropbox api but did not see anything stand out where this was possible.
It's very sad to realize that a popular platform such as Dropbox doesn't expose A LOT of basic features through its API (and the SDK itself is far from being OK, compared to G-Suite). Anyway, there are two hacky methods you can use in order to pull out that information (with some limitations).
First method:
By analyzing the team events using team_members_list() you can filter out tfa_change_status_details events. When new_value=TfaConfiguration('[sms|other]', None) is specified - 2FA is enabled.
The information I found out that can be retrieved using this method is:
has_2fa - whether 2FA was ever configured.
is_tfa_enabled - whether 2FA is currently enabled.
tfa_type - whether 2FA is by SMS or by app.
However, keep in mind that you have to track changes constantly and also keep in mind that Dropbox saves team events for only two years.
Second method:
Using the front-end dashboard API this information can be retrieved (I can't remember the API name, I think that it is /2/get_multifactor and inside you'd find some information about its status and the organizational policy regarding 2FA). However, to use the front-end dashboard API (which is totally undocumented) you'd need to simulate a successful login (and correctly use the lid and jar cookies) and you'd also need to bypass the random captcha that appears when you abuse the service with too many requests.
To be honest, Dropbox's API is weak, neglected, and ugly. I wish I never had to use it. Anyway, I would recommend using the first method and pray for a significant update to the API
No, unfortunately the Dropbox API doesn't expose this. We'll consider it a feature request.
There's a feature request open for this one (https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/MFA-status-for-users/m-p/468564#M23886). But I wouldn't hold your breath, as #Aviv mentioned the Dropbox API seems surprisingly neglected at the moment.

How does the Dropbox Datastore API differ from Parse?

How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.

Is there a way to register an application on Google+ like on Facebook?

In particular I'm interested in the possibility of getting an App Access Token with no expiration time, exactly as I do with Facebook.
I want to publish on behalf of the user via server, and I found very useful and convenient the Facebook's procedure in which we ask for the user permissions only the first time.
I have been working with this kind of social-networks interaction for merely three weeks, so I will be very happy to hear any type of suggestions or critics.
Google+ does not currently have a public write API. There are selected partners that they work with (such as HootSuite) that provide this feature, but they are making access to it available very slowly. See https://developers.google.com/+/api/pages-signup for further details.
Google+ does have a concept of Moments, which are activities that happen in your app that are reported to Google+ and which the user may later wish to share, or may make available to people in their circles on a limited non-notification basis. This is probably not what you want, but may serve some needs. See https://developers.google.com/+/api/latest/moments for more info and examples how to use it.
Simply, No there is no way to do that in Google+ in current time. In general, apps for Google plus is read only.