Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App Redirects #147

Open
larrysalibra opened this issue Sep 3, 2019 · 8 comments

Comments

@larrysalibra
Copy link
Member

commented Sep 3, 2019

A number of apps redirect users to different origins from the origin submitted to app mining. (https://example.com is one origin, https://alice.example.com is a different origin).

Blockstack's security model is origin-based - a different origin is a different app. It is important that users understand which app they are using and redirecting between multiple origins hurts that goal.

Proposal: App developers must submit the origin of the app they wish to review. Redirects to other origins will not be reviewed.

@Walterion1

This comment has been minimized.

Copy link

commented Sep 3, 2019

@larrysalibra about this issue, will you consider sharing auth between multiple apps? like x.app.com and y.app.com like what Microsoft or Google apps doing so users don't need to sing in every time.
Or you consider this as this issue?

@friedger

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2019

App publishers should submit

  • a url for the landing page and
  • the app domain.
@kkomaz

This comment has been minimized.

Copy link

commented Sep 3, 2019

I agree with @friedger on this one.

Especially with TryMyUI testing, the audience needs to have context of the application use case. Isn't this pretty standard practice of using the domain/subdomain?

Landing page is a separate repository a static page focused on SEO.
App page is a separate repository specific for the app use case.

What do you think about...

If TryMyUI -- Direct them to the landing page
If Nil -- Direct them to the app page

@larrysalibra

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2019

I agree with @friedger & @kkomaz's proposal as well.

the audience needs to have context of the application use case

This makes sense to me.

will you consider sharing auth between multiple apps? like x.app.com and y.app.com like what Microsoft or Google apps doing so users don't need to sing in every time.
Or you consider this as this issue?

@Walterion1 I know redirects are common in the existing web, I believe this is bad for users because they enter a url thinking they're going to one place and interacting with one domain and then get redirected to some other place entirely outside of their control. Wanting to have two apps accessing the same data seems like a perfect use for collections.

@larrysalibra

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2019

I agree with @friedger & @kkomaz's proposal as well.
I'm having second thoughts about this already.

Why can't you have marketing pages and other pages of an app on the same origin?

How you want to organize your development of the app doesn't seem necessarily connected to how it is presented to the user. It's not hard to do it all on one origin.

If a user a user visits example.com and is sold by that site on using the app and clicks the sign in button, they should sign in to example.com, not some other origin.

I think this makes more sense in a world where apps are distributed by blockstack names. With blockstack names, alice.example.id and example.id are not assumed to be controlled by the same party. The owner of example.id doesn't have any control over alice.example.id.

@Walterion1

This comment has been minimized.

Copy link

commented Sep 3, 2019

Yes, collections are on my waitlist.
So you prefer a mobile app way, every app using the separate set of permissions. I like it, but today users are not a fan as we had some angry emails or even TMUI testers that said: "Why I should sign in again?"
Maybe it needs a learning curve for users.

@kkomaz

This comment has been minimized.

Copy link

commented Sep 3, 2019

If a user a user visits example.com and is sold by that site on using the app and clicks the sign in button, they should sign in to example.com, not some other origin.

I think this is the issue of SSR vs. SPA. SPA is horrible for SEO but great for application development. SSR/Static is great for landing but can be either too simple or complex depending on the use case of your app. Thus the separation.

@friedger

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2019

Maybe it could be helpful to just submit a link to the web manifest. The app domain can be deduced from that. (and it would help to reuse the information for theblockstats.com or app-center.openintents.org)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.