Why is Slengpung frozen since 2020?
category: general [glöplog]
There is now a static sidebar when the screen width is wider than 768px. The group search chrome bug was fixed. The party photo picture link was fixed.
Defiance: Like... how? To show an image with less resolution on small screens? Since I only have one version of all the images, which would be the biggest resolution available. Or do you mean that the pictures would scale with the window sizes, which they do.
Defiance: Like... how? To show an image with less resolution on small screens? Since I only have one version of all the images, which would be the biggest resolution available. Or do you mean that the pictures would scale with the window sizes, which they do.
the link leads to a white page..?
sorry about that, the sidebar commit broke the layout there. fixed now.
ok it works now, seems a bit minimalist so i'll check back later
being a photographer for slengpung was a big part of my identity and activity as a demoscener from the early 2000s to the late 2010s. seeing the project frozen was, without exageration, very traumatic for me. so, T-101, MANY MANY THANKS for attempting a new version! if i can contribute somehow (as a non-coder), please let me know. and once it is up, i will take up the task again to hunt down photographers and old party pics, and enter them into the db, just like i used to do for over 20 years. actually, i have old party photo submissions from various people lined up from the last four years, and can't wait to contribute them to the site.
Quote:
I'm also thinking that those uploads should go through an admin for review before being posted on the site.
Yes, please, this is an absolute must. Original Slengpung was a curated site, not only for obvious anti-spamming/trolling reasons, but also to prevent the coverage of a party being 50+ pics from one scener and their friends/crew. It would be nice to keep this curated character at least somehow.
Scaling so that the entire image fits in the window without scrolling up and down to see it whole... but again if it is too much to ask, no worries! :)
Defiance: what device, resolution and zoom level are you using? I have yet to encounter a configuration where I'd have to scroll to see the image?
T-101: feature request - implement swipe gestures on mobile so we can flip through images without having to tap the previous and next button, would make browsing on a phone a lot more comfortable, imho.
T-101: feature request - implement swipe gestures on mobile so we can flip through images without having to tap the previous and next button, would make browsing on a phone a lot more comfortable, imho.
LJ: swipes enabled
confirmed, thank you!
Looks promising so far. Even works with noscript :)
i'm team 'das war ein mal', so good riddance
While writing the sceneid integration bits today, I started thinking of the logistics of matching a sceneid user to a slengpung user.
All of the data I have from the old slengpung is what I scraped from the site. I have usernames, groups, user to group relations, parties, photos and comments. Nothing more. As it stands currently, it is impossible to match users.
If this is to move forward, I would need some sort of dump of the old database. But I have no idea what it looks like. If the passwords are stored in plain text, then that is just horrifying. ROT13 and md5 are equally bad. But if they are hashed in a way that cannot be reversed, then we may have some room to wiggle here. Also, if there is a mapping of sceneid <-> slengpung user id, then that would also be awesome. That would obviously be incomplete, it would be by far the easiest and safest way since it holds no credentials.
But if the passwords are stored in a way that would allow me to turn them into plain text, I don't want them. I don't even want to hear about them. In that case there might be a possibility to make a a secret API which the backend would could call with the credentials entered by the user, and it returns slengpung user id if they were correct, or nothing.
So that's what I've been thinking today.
Also, I fixed all the bugs reported in the feedback system. Thank you for those reports!
All of the data I have from the old slengpung is what I scraped from the site. I have usernames, groups, user to group relations, parties, photos and comments. Nothing more. As it stands currently, it is impossible to match users.
If this is to move forward, I would need some sort of dump of the old database. But I have no idea what it looks like. If the passwords are stored in plain text, then that is just horrifying. ROT13 and md5 are equally bad. But if they are hashed in a way that cannot be reversed, then we may have some room to wiggle here. Also, if there is a mapping of sceneid <-> slengpung user id, then that would also be awesome. That would obviously be incomplete, it would be by far the easiest and safest way since it holds no credentials.
But if the passwords are stored in a way that would allow me to turn them into plain text, I don't want them. I don't even want to hear about them. In that case there might be a possibility to make a a secret API which the backend would could call with the credentials entered by the user, and it returns slengpung user id if they were correct, or nothing.
So that's what I've been thinking today.
Also, I fixed all the bugs reported in the feedback system. Thank you for those reports!
Oh yeah and someone was wondering why so many pictures from parties are missing.
I've only imported roughly 30% of images there, bringing us up to the year 2004.
I've only imported roughly 30% of images there, bringing us up to the year 2004.
I would recommend to drop having your own user database completely. The whole SceneCity system is working without storing any user data at all.
What you could do: If users first authorize Slengpung to access their records via SceneID, on the redirect back to your site try to match their username with your old Slengpung user name list. If there is a perfect or close match, ask the user "Is that you?" and if answered yes, add the SceneID username to that table row.
After all, the only ones who would care about their old Slengpung username being correctly mapped to their SceneID would be people who want to log in. Those who do not log in will be fine with the old static record about them.
What you could do: If users first authorize Slengpung to access their records via SceneID, on the redirect back to your site try to match their username with your old Slengpung user name list. If there is a perfect or close match, ask the user "Is that you?" and if answered yes, add the SceneID username to that table row.
After all, the only ones who would care about their old Slengpung username being correctly mapped to their SceneID would be people who want to log in. Those who do not log in will be fine with the old static record about them.
scamp: the way django authentication works, is that django needs to have a user record. having a user in django also is needed when we talk about user specific settings (denying search, etc). without authentication all you see is the login screen.
now, if I were to implement a "guessing" system to match sceneid users to slengpung users, it presents a very nasty security hole. example: I go to id.scene.org and change my display name to "scamp". I then login to the new slengpung, and the backend receives my display name as literal "scamp" and allows me to connect. I dont like the prospect of that. and I'm guessing neither do you :)
now, if I were to implement a "guessing" system to match sceneid users to slengpung users, it presents a very nasty security hole. example: I go to id.scene.org and change my display name to "scamp". I then login to the new slengpung, and the backend receives my display name as literal "scamp" and allows me to connect. I dont like the prospect of that. and I'm guessing neither do you :)
Don't use Slengpungs display name for anything related to authentication, use the username. The display name is non-unique.
(In SceneCity the users can freely change their display name Independent from their SceneID setting, but the username coming from SceneID is used as unique key)
Also, in general: Don't assume that much malice. I could hardly imagine someone wanting to impersonate me to... do what? tag a picture of Frankenstein to be me?
also, a reason to connect sceneid and slengpung users, is to allow the user to detag themselves should they wish to do so.
I get where you are going with this. when a user logs in, I get the unique sceneid id number, and that is the only way I use to differentiate between users in that regard.
I dont assume malice, but I also don't disregard the possibility of it. having seen what folks try to do to partyman when it is running at assembly has tought me a thing or two.
I dont assume malice, but I also don't disregard the possibility of it. having seen what folks try to do to partyman when it is running at assembly has tought me a thing or two.
It would be cool if SceneID would report back the registration date of an account. As all Slengpung accounts that need to be remapped are by definition "old", that would work well for you.
And it would also help in other cases - should we ever get a problem with a banned user just coming back with new SceneID after new SceneID, the registration date would help to slow that down.
I'll ping Gargaj with this feature request, maybe that field exists and he just needs to expose it.
And it would also help in other cases - should we ever get a problem with a banned user just coming back with new SceneID after new SceneID, the registration date would help to slow that down.
I'll ping Gargaj with this feature request, maybe that field exists and he just needs to expose it.
Had a good 70+ min chat with Gargaj about this, ALL of this. I'm now much more informed, and I now know the steps I need to take before this goes forward.
It's not all bad news! Just a few more bureaucratic steps than I had anticipated. And a few more points to consider that I possibly couldn't have thought of.
It's not all bad news! Just a few more bureaucratic steps than I had anticipated. And a few more points to consider that I possibly couldn't have thought of.
Friendly reminder for every coder with an unfinished project out there: Rome wasn't built in a day! :)
T-101: The user system is an optional part of Django. Most coders I see think somehow that it isn't, but it really is. It's not really all that good, and it sucks at integrating with other systems, so you could consider just… not using it. :-)