[feat] Don't rely on an intermediary server for logging in

[moeenio]

As discussed in #30 with @Semisol It would be better to bypass CORS restrictions and log in to Scratch directly than use an intermediary api server that gets your password. This can be done with a capacitor plugin as shown in this article. This desn't remove the need to write a pirvacy policy, though.

@micahlt

[micahlt]

Agreed. The only downside of implementing the HTTP capacitor plugin would be that the app can no longer be tested in the browser because of CORS restrictions. That will rapidly slow down development. I'll look into it and see if I can find a method of doing it.

[Semisol]

Agreed. The only downside of implementing the HTTP capacitor plugin would be that the app can no longer be tested in the browser because of CORS restrictions. That will rapidly slow down development. I'll look into it and see if I can find a method of doing it.

Well do you know that there is something called a browser extension to temporarily disable CORS and also a custom backend option for testing on desktop?

[micahlt]

@Semisol Ah, all righty. Guess I'll work on implementing this ASAP and updating the docs to reflect the changes.

[moeenio]

If we don't want to rely on the server for logging in, we shouldn't rely on it for actions that need a token too huh?

[micahlt]

@locness3 Maybe, or maybe not. That would solve rate limiting issues we'd have when using a single server. However, for my wrapped API's that I'm working on (like studios, for example, which don't even have a JSON-based API), that could dramatically increase the app's file size.

[moeenio]

I think it's ok to rely on the server for public data. for anything private (including actions on public things) the app should do it directly; a token is as powerful as a password.

[micahlt]

That's fair. I can attempt to integrate my studio wrapper directly into the app.

[micahlt]

Unless anyone else is willing to work on this, I'm going to have to leave this as it is. For some reason I absolutely cannot get auth working with the Capacitor HTTP plugin. I've been working on this one issue for around one and a half months, and it's gotten me very burnt-out. For now, login will go to the server which will send the x-token back to the client where it will be used to authenticate other requests directly to Scratch.

[moeenio]

what about you learn java or kotlin?

[micahlt]

I really don't have the time or resources to learn an entirely new programming language, and I'm definitely not starting over Itchy for a third time.

[moeenio]

I still have to do it then.

But trust me when I say that Java is easy to grasp from JavaScript.

[micahlt]

I still have to do it then.

What do you mean?

[moeenio]

Making a native client... maybe not.

[micahlt]

Oh my - good luck with that! 😣

[moeenio]

Lmao

[micahlt]

I'm putting this in the backlog - this doesn't harm the user experience and I cannot get this to work.

[moeenio]

every task on this project be like

[micahlt]

every task on this project be like

Not really - I'm still hard at work on getting this released before 2022. I don't care if anyone else contributes anymore. No one except you seems to actually contribute anything to the project.

[moeenio]

No one except you seems to actually contribute anything to the project.

True. Advertise!

[micahlt]

No one except you seems to actually contribute anything to the project.

True. Advertise!

What do you think all my Scratch projects are doing lol

[moeenio]

I've changed the labels since I consider this to be an important security bug. Feel free to change them back.

[micahlt]

Are you going to pursue this issue? Also, this isn't a bug - it's a workaround. There's a difference.

[moeenio]

Are you going to pursue this issue?

Wdym?

Also, this isn't a bug - it's a workaround.

Sure.

[micahlt]

Are you going to pursue this issue?

Wdym?

Are you going to work on this? I've already put forth my best effort and made exactly 0 progress.

[moeenio]

Possibly.

[Semisol]

I do not know how any of this native stuff works. All I have to say is I would not want to trust my token with a service, and others would not too.

[micahlt]

@Semisol I'm sure, which is why signing in to Itchy is completely optional. The only explanation I can give you is that instead of using JavaScript's native fetch API, we're using Capacitor HTTP which is supposed to make the requests through native Java code, therefore bypassing CORS requirements of the Scratch API. However, it's not a perfect plugin and some things just won't work. I've duplicated the login request exactly as used in itchy-api using the Capacitor HTTP plugin, and it won't work (e.g., gives 403 errors on request). I can, however, reassure you that the current auth server (itchy-api) is completely open-source and hosted on a secure platform (Vercel) that logs no private information.

[moeenio]

Did you try to reach out to the devs of the Capacitor plugin?

Also : is it not possible to test the app in the browser anymore with the http plugin? would using a proxy depending on the detected platform be a solution?

[micahlt]

Did you try to reach out to the devs of the Capacitor plugin?

Yes, I have. From their testing, cookies are working fine (which is the issue I'm encountering). I suspect it's partially an issue on Scratch's side.

is it not possible to test the app in the browser anymore with the http plugin?

My current method of testing online is with a CORS-bypassing extension that automatically proxies requests when turned on.

[moeenio]

My current method of testing online is with a CORS-bypassing extension that automatically proxies requests when turned on.

Right, didn't think of that - not sure if cookies would work with this?

[micahlt]

Not sure either - which is why during development I generally just use Capacitor hot-reloading over ADB with my phone rather than the browser.

[moeenio]

That's useful, however it requires the android sdk

[micahlt]

That's useful, however it requires the android sdk

Lol of course - this project is an Android app.