Computers get faster all the time, making brute force cracking of passwords easier all the time. Password managers don’t care how long a password is. The task of filling it out is the same.
60 character passwords with any amount of complexity would take effectively infinite time to brute, an 18 character password with complex characters would take millions of years… There is no reason to use 60, let alone more than
Well, there could be very reasonable reasons for the limit, like keeping the hash tables sane, or keeping databases from needing unnecessary padding, but there really isn’t any reasonable reason for needing 60+ characters in passwords
Well, there could be very reasonable reasons for the limit, like keeping the hash tables sane, or keeping databases from needing unnecessary padding, but there really isn’t any reasonable reason for needing 60+ characters in passwords
And how is this the duty of a client app to police that? OP says it’s about being able to log into their own instance and the client app is blocking this.
Also, none of those is a sane reason to limit password length. A huge point of hashing is having short, constant length strings on output no matter the input. There’s no limitation or database issue there.
The only reason to limit password length is actually security (for bad algorithms) and DoS, but that requires a limit in the thousands.
True. What annoys me the most in apps in general (Jerboa included) is the practice of losing your draft at the minor deviation of usual workflow. You gave the example of hitting the top bar, but the same happens when there’s a connection issue or if the app crashes or is closed by the OS to manage memory.
It sounds a little extreme but I recommend a self-keylogging app. The OS doesn’t let them read password fields, you can generally exclude entire apps you don’t want logged, and you can set how long the app holds onto your logs. Look for one that doesn’t request internet permissions, of course.
Hey there! There should be a setting which enables this function. The setting is under Feed in Settings -> General and is called “Mark Read After Viewing Media”
Let me know if you can’t find that option or if you have any other questions!
Thanks for the kind words, we really appreciate them!
We’re still hard at work to make even more improvements to Thunder as a whole, with a greater focus now on improving general performance and stability of the app. Thunder is still a project that all of us contributors (including me) work on during our spare time, so its nice to hear that others are using and enjoying Thunder 😄
I just wanted to say thank you for not making an Apollo clone.
I loved Apollo. It was a great app. But its UI seems to have short circuited the UI design of nearly every Lemmy app. If they don’t blatantly say they’re copying Apollo, it’s clear they are.
I like how you’re going in a different direction and trying new things. The Floating Action Button is a great example of trying to do something different.
Thanks so much to your dedication to this project!
Working on this project is all about learning (at least for me), so I like to explore different avenues for creating something without necessarily copying another existing app. Rather, I’d like to think that Thunder combines some of the cool and interesting features scattered across all the other apps into one place.
I’ve personally used Apollo, so you’ll see some hints of Apollo’s UI even here (swipe gestures is one of them) 😅 If you have some feature or idea that would be nice to have in Thunder, you’re always free to open up a new issue on GitHub!
So what I have noticed is 60 is the max according to the source code, but if you use a password manager that fills the field in for you, the browser in my case Firefox, ignores the limit and accepts the full length password.
Hey there, like others have mentioned, I think this is a limitation on lemmy’s end which limits the password length up to 60 characters.
This is the source code for lemmy’s backend if you’re curious. If you think this is not the case, feel free to create a new issue on GitHub and we can take a further look into this! Let me know if you need any more clarification :D
I think that check must be bypassed for admin passwords, or it was instituted after I created programming.dev, because my password is 100 characters and I can log in on every other app perfectly fine. Even if that was the limit, it still should be enforced by the backend on login, not on the frontend, except for maybe initial account creation.
I think that check must be bypassed for admin passwords, or it was instituted after I created programming.dev
That could be a possibility - we can do some tests to verify if that’s the case. I found this related issue which might indicate that all auth flows through the same logic.
Even if that was the limit, it still should be enforced by the backend on login, not on the frontend
Unfortunately, that might not be the case. Dessalines mentioned in this comment that the backend doesn’t truncate overly long passwords, and throws an error instead. Although, as you mentioned, this might be bypassed for admin users.
Either way, I think we can take a deeper look at this and verify this information! Feel free to create a new issue for this on GitHub if you’re able to so that we can track this issue better.
Thanks for the update! I’m looking forward to the next release. Is Thunder Nightly the one on testflight? Or is there an even more alpha release I can get?
Just wanted to give you an update that the TestFlight pre-release version is currently under review, and should be available sometime later today! (if all goes well)
The post UI appears to have the create post button at the top also, and have that same potential to lose your text by accidentally catching that bar when swiping to try to scroll down.
Thanks for the question - this is a feature that is currently being worked on and should hopefully be available in the next general release for any lemmy instances running 0.19.0 and above. The main delay here was waiting for lemmy to natively support blocking instances.
If you’d like to keep track of the on-going progress for this feature (and general support for lemmy 0.19.x), see this GitHub issue!
Oh wow, are you on a beta or something? Or do you know how you enabled it?
Update: Got the latest version from GitHub and now I have it. I guess the dev hasn’t put the latest version in the Play Store for some reason. Thank you!
I would say it is in most situations. Then they could have a reason on top of that for not actually going forward with the release after validation, no idea. I’m not from the team, just to clarify
Hey there! Comment navigation should be available on the latest general releases on Google Play and App Store (it was introduced in a previous version v0.2.2+15). It could be possible that you had that option disabled (Settings -> General -> Comments -> “Enable Comment Navigation Buttons”)
The releases on GitHub contain the latest nightly builds of Thunder, which are updated more frequently but are more prone to bugs since they are more “experimental” in nature. I hope this clarifies some of the questions!
Thank you all for your hard work and for your update!
I checked the change log but I didn’t see anything about it, so I’ll ask here (and if it’s preferred I’ll also ask on GitHub): are there any plans for eventually enabling the search option to search for comments and/or posts too by any chance?
Hey there! We do have a existing GitHub issue on this but we haven’t been able to get around to it just yet due to other priorities. If you would like this issue to be prioritized, feel free to give the issue a thumbs up so that we know!
Here’s the GitHub issue. Let me know if you have any other questions!
thunder_app
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.