Jump to content
You're invited! Join our 4.6 Live Event on ZOOM 6/24 ×

Community

Colonel_mortis

+Clients
  • Posts

    1,380
  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Colonel_mortis

  1. If the user disables the map, the EXIF data is still retained on the image (when using Imagemagick), so this gives the user a dangerous false sense of security that their location is private. All I need to do is download the image and I can extract the location.
  2. Ah, you seem to be right. I guess I must have been thrown off by the method name, because I did think I had checked how it worked. Nothing to see here. However, I would still like to see the user being given the option to use the name or choose another, rather than it being an admin decision, or at the very least it shouldn't count towards their username changes.
  3. The following is from the Facebook login handler; other default login handlers are largely the same /** * Get authenticated user's username * May return NULL if server doesn't support this * * @param string $accessToken Access Token * @return string|NULL */ protected function authenticatedUserName( $accessToken ) { if ( isset( $this->settings['real_name'] ) and $this->settings['real_name'] ) { return $this->_userData( $accessToken )['name']; } return NULL; } This function does not fulfil the contract specified in the documentation - the server does support getting the name, regardless of the real name configuration. By returning NULL when real name import is disabled, my name won't be shown when in my account settings, or in ACP. This is not good, and defeats most of the point of displaying the name in UCP/ACP in the first place. Moreover, the whole username import process is not fit for purpose in my view. If I create an account, I don't want to be forced to use the name from my social service, especially as when that feature is enabled it counts as a username change, so I can't actually change it for some time (as specified by the admin, 180 days on my site). I would, however, like my name to be prefilled in the username box, at least when connecting to a site that doesn't use my real name. Also, on some third party sites, my display name and my username might be different, and I would like my display name to be prefilled when creating my username here, but I would like my username to be displayed when viewing my account link in my settings (and ACP). A concrete example: I want to let people use their steam name, but lots of people on Steam have clan tags in their usernames, which would not make sense on my site. They should get the option to edit their name to remove these clan tags before creating the account. Another concrete example: On discord, my display name is, say, "coolName". There can be multiple people called "coolName", so internally I am actually "coolName#1234", and this is displayed in some places. When I create an account, I want "coolName" to be prefilled in the box, but when I view it in my account settings (or, more importantly, in ACP), I want to see that it's actually coolName#1234. You can fix this by removing all the useless stuff from authenticatedUserName, and just prefilling the username box with the value from it if available. If no name is available, it will behave as it does now, but if the service provides a name it can be prefilled magically (or, if you really thing users appreciate less friction over having their real name displayed next to their posts without getting a choice about it, you could give admins the option of automatically creating the account with that name, but it should be an OPTION). Ideally, also add another method for getting the name to display in account settings and/or ACP (separate methods would be nice, but the same is fine), which defaults to the name returned above, but lets me return a different value if I so desire.
  4. And yet I still see people asking how they can add a local password. Using "forgot your password" when you never had a password is not intuitive enough for all of my relatively technical users (I of course don't have figures for how many people figured it out on their own, and how many people looked at their account settings, couldn't see a way to add a local password, and gave up).
  5. There are a few reasons that spring to mind: They want to be able to log into a device that they're not signed into Facebook on, or a device where Facebook is blocked (school, work) Privacy - if they signed up with facebook, but no longer wish to grant other sites access to their Facebook data (which includes their real name), they would want to switch to local login (since switching to Google/Microsoft/etc would shift but not solve the issue) They want to delete their Facebook/... account Security - at least to me, I would rather not need to place extra trust in a third party service (and rely on it having been connected correctly) as well as the existing trust that I need to have for the site itself. While I am sure that there is no risk, I still don't permit anything other than local passwords for ACP login. Redundancy - third party logins have failed in the past (usually due to problems on my end, but that doesn't actually matter), so having a way of logging in when that happens is useful (they can use the reset password link, but that is not communicated to users). Personally, I try to keep everything isolated to one site, so I very rarely use social login options. That way, no matter what happens to Facebook, my account on websiteX will be safe, and no matter what happens on websiteX, my account and data on Facebook will be safe.
  6. In 4.3 (I think), you added support for LOGIN_REAUTHENTICATE, which you use to verify a user's authenticity when changing their email or 2FA credentials. This means that the ability to authenticate by a method supported by LOGIN_REAUTHENTICATE is sufficient to add a local password anyway, as you can change the email then reset the password. LOGIN_REAUTHENTICATE supports reauthentication using social login methods such as Facebook. However, there is still no UI support for adding a local password if you currently only have social logins enabled, so you have to go through the password reset process. This is poor UX, and is not at all clear to users who are trying to add a local password (there is no message that they should do this). As there is negligible security benefit of the current system, I think it would make sense to allow users to add local passwords in the same way as users can change their existing passwords, but allowing them to authenticate using a social login to gain access to the new password form.
  7. Yes, but my point is that I shouldn't have to. While there might arguably be reason for leaving the settings intact (such as recovery in case something screwed up), there's no reason to leave the task. It has been removed from the dev install, and there is no indication when you remove it that it won't be removed from the live installs.
  8. This feels very much like a bug, but the IPS core code appears to deliberately work around it. If you delete a task in the dev center, it removes the task on the dev install (including the task's PHP file), and removes it from the tasks.json file so it isn't installed on any new installs. However, when the app is updated on an existing install it only updates existing tasks and adds new ones - it doesn't delete the tasks that are no longer required. For a traditional setup, this results in the task continuing to be run, because the old PHP file won't be deleted. I deploy most of my stuff through git, so for me and some other large sites this results in the task failing because the file has been removed but the task has not. As there is core code that works around this (by deleting tasks on upgrade), I guess this is probably something that is sort of known, but it's definitely not good and should be changed. It makes no sense to do it this way.
  9. Or it should be an extra option. If I ignore a member, I don't just not want to see the posts that they make within a topic, I also don't want to see the topics that they have posted. This has been requested by a few members on my site.
  10. Suggested to me by a member. Especially when you're pasting images into the editor, but also when reviewing attachments associated with your account, it would be useful to be able to rename them to make certain files easier to find, so that they can be referred to elsewhere.
  11. As much as I would absolutely love IPS to switch to a better language, like Go, the big benefit of PHP is that every webhost supports PHP, but very few will support any compiled languages like Go. While many more technical users are running on a VPS, there are a lot of people still using shared or managed hosting, and I would be quite surprised if IPS dropped support for them any time soon. Perhaps if CiC became much more reasonably priced there could be an argument for it, but it would still cause a lot of complaints I expect. If they did switch language though, and go through the whole process of retraining their staff, I don't see any reason to stick with PHP for any part of it - if you're going to do a service-oriented architecture like that, you might as well do the front end using a framework like react or angular, and just do an API backend. Again, I would really love it if this did happen, but it seems pretty unlikely to me.
  12. The 4.3-style announcements look really nice, and a big improvement over the earlier versions. However, I still have a couple of issues with them that I think would be super easy to solve and would make them much better: Allow announcements without a description, or that link somewhere else. Spoiler alert: you want this too - on this site you have a commented out banner which is exactly what I'm asking for: (but with the option of it just being a link to somewhere else too). This would be used for things that don't need any more content, like "Site maintenance tomorrow", and references to other areas, such as the rules. Make the announcement areas more consistent. Currently the top announcement has a "Read more" link, the contentTop announcement is all a link and has a bullhorn at the start, and the sidebar announcement has a bullhorn at the top of the block, each announcement is entirely a link, and has a random (i) icon at the end. This is not great UX. The announcement sidebar block doesn't show unless you have another block in the sidebar - there's no way to display just the announcements. While it's useful to be able to not show announcements or the sidebar in general on a page, I could plausibly want to show the announcements and nothing else. It's also pretty poor UX when adding blocks, because the announcements don't show up/disappear until you refresh the page. Fix these (especially the first - I can tweak the second in themes and the third doesn't actually matter to me personally) and I will be very happy with announcements.
  13. Unfortunately the editor uses inline scripts, and there's no way to avoid that with the current editor (it currently uses CKEDITOR 4, and it's fixed in 5, but that is a huge change which drops support for all existing plugins and all but the most recent browsers, so isn't something that IPS can even begin to consider until at least 4.4, and quite possibly later). If you enable unsafe-inline in your CSP, it makes it effectively useless, because in almost all cases if you can inject a script hosted on a remote site, you can inject the script body locally. A CSP is a security feature rather than a solution for privacy or unwanted content - there shouldn't be anything that you, as the site owner, don't want in the first place.
  14. Currently, all metadata, including GPS data, is preserved on all uploaded images when using ImageMagick (but I believe not GD - it seems to be stripped on this site). Many phones have location tagging enabled by default, and users are unaware that uploading their photos might compromise their location. In the gallery, location data can be retained in the optional map, but in the image itself, and everywhere else on the site, I think GPS data should be stripped to protect users' privacy. How accurate is the GPS data, you may ask? My location was accurate to within under 10m. If I posted my test image here, you, and the rest of the internet, would get a terrifying amount of information about me. nb. I've only checked with 4.2, so it is possible that this was changed for 4.3.
  15. At the moment, changing the sort method for a forum updates the URL, so it doesn't persist when you come back later. I, and a few users who have requested this, think it would make sense for the sort option to be saved, perhaps optionally, so that users can decide the sort method that they want without needing to change it every time they want to use that forum.
  16. In downloads on my site, we have files of 2GB+, and I don't think we had to do anything special to support that. There is a 4GB limit because the file size is stored as a 32bit integer in the DB, but that was the only limitation that I'm aware of.
  17. They already do use chunked uploads. On this site you can't test it because they're using S3, which I believe doesn't support chunks, but if you are using the file system and you try to upload a large file, it will chunk it. On my site, the chunk limit is 30MB (I'm not sure off the top of my head where that limit was pulled from though), and I was able to upload an 83MB file without issue, with 3 requests being made to the server to upload it.
  18. If you use a password manager to generate a password that is more than 50 characters, and paste it into the password field when setting/changing your password, you will then be unable to use it to log into your account, and have to reset your password to regain access. I reported this in a ticket, but apparently it's "by design". The original contents of my ticket are as follows: On the registration, password change and password reset pages, you cap passwords at 50 characters. I don't see the point of doing this, and would be in favour of removing an arbitrary limit, but I accept that a 50 character password is (as long as it's remotely sensible) sufficiently strong for any purpose. However, that limit is sent to the browser as the maxlength attribute on the password field. The problem with a maxlength attribute is that, even when applied to a password field, content that is pasted into it is truncated to that max length. If I generate my 64 char password using a password manager (which doesn't autofill it into the field), and paste it into the password field, it is therefore truncated to a 50 char password with no indication that this has happened. I then save the 50 char password on the site, as well as the 64 char password in my password manager. When I come to log in, I paste in my 64 char password into the login form, and it pastes in its entirety because there is no max length on the login form (and there must not be one, because passwords created before you introduced the max length can be more than 64 chars). The password therefore doesn't match what is stored in the db, because it's 14 characters too long. Proposed solutions, in order of my preference: Remove the arbitrary limit on password length, or increase it to a value larger than password managers would ever generate, such as 500. Reduce the arbitrary limit to ≥72, which is the length that the passwords are truncated to for use with blowfish anyway, so even if the password is truncated without the user's knowledge it doesn't actually make any difference. Remove the maxlength attribute from the html for password fields, and process it exclusively on the server (or using JS), so users receive an error when their password is too long, rather than it just being truncated. To clarify, there is no visual indication that there is a length limit of 50 characters, so the user has absolutely no reason to suspect that their password won't have been updated correctly, or to suspect that the password length was the reason for their account being inaccessible.
  19. @Ahmad E. If a user has set their account up to sync their profile picture from Discord, then changes their picture in Discord, their image 404s on the forum because the new image has a different URL. Would it be possible to import the picture into the uploads dir rather than serving it from the Discord CDN, or to periodically check that the image URL hasn't changed? I'm an alt contact for a site that has purchased this extension, and can provide proof of purchase in a PM if needed.
  20. Have you customised your themes? It looks like the who's online widget is breaking, which is causing an infinite loop of trying and failing to display the error page. There should also be entries in the System Log in ACP (on the support page, in the bottom right) which give more details of the original error triggering it.
  21. Agreed, especially as complying with user requests to delete accounts is required for compliance with the GDPR.
  22. To me, it was annoyingly inconsistent in 4.2, and some change is welcome. However, I think a compromise should be made if possible - the quote popup should appear at the end that you finished the selection, so if you selected from left to right it should appear at the right, and vice versa. That way, it should always appear next to the cursor without resulting in the weird behaviour from 4.2.
  23. Suggested by my users, and it makes sense. There's already a crop tool for profile pictures, so why not let you double click on an uploaded image and crop that too?
  24. It's been a while, any chance that this will make it into 4.3? It would be really useful for undoing moves made by staff members, either because the move is contested or because it was moved to a temporary area to resolve an issue.
  25. This would be really useful, and is something that my staff have requested numerous times.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy