wohali

+Clients
  • Content count

    192
  • Joined

  • Last visited

2 Followers

About wohali

  • Rank
    Member

IPS Marketplace

  • Resources Contributor
    Total file submissions: 5

Recent Profile Visitors

2,801 profile views
  1. v1.2.4 released to fix a minor regression where the new URL path was not displaying correctly in the ACP details for an OAuth integration.
  2. v1.2.3 posted to fix a regression with the token expiry task. Note: If tasks refuse to run in your IPS instance, it may be necessary to run the following command against your IPS SQL database to fix the OAuth 2installation: DELETE FROM enco_core_tasks WHERE `key` = 'expire_tokens'; The alternative would be to fully uninstall, then reinstall the OAuth2 Server application.
  3. v1.2.1 posted. New features: Language strings are now used for all text in the authorization form template displayed to first-time users of the OAuth integration. New scope support for user reputation points. Request user.reputation in the scope string for this data. (Thanks @Recouse!)
  4. v1.2.0 is uploading now. Here are the release notes: Fixes for IPS 4.1.14. Note that v1.2.0 is not backwards compatible with 4.1.13 and below. For older IPS releases, please continue to use v1.0.1. Scope support is complete and now recommended for Rocket.Chat integration. Allowed scopes can be specified in the ACP on a per-application basis Scopes can (and should!) be specified on initial authorization requests. If none is specified, all allowed scopes for the application are authorized. The initial form that displays to users asking them to approve the authorization request lists which scopes are being requested by the OAuth Application (Client) User primary and secondary group information is available by adding the user.groups scope to your initial authorization request. Rocket.Chat integration steps are documented in an included RocketChat-Readme.html file which is viewable on GitHub. Up-to-date documentation can always be found at GitHub.
  5. Excellent, glad to see there is a workaround for now. I have a plan to support scopes in the plugin but it's going to take a little bit of time. I will see if I can fix the scope support before releasing 1.1.0, but if it takes too long will get this fix out there so people are not blindsided by the 4.1.14 release.
  6. Shoot. I can't reproduce this on my site, the integration works correctly now for me. Can you try full uninstalling then reinstalling the OAuth integration from IPS, then install the beta for me and try again?
  7. OK @RevengeFNF and others, I'm attaching a beta of Oauth 2 Server 1.1.0 to this message. This should solve your problems, and should be backward compatible with IPS 4.1.13 and lower. The issue was not, in fact, the Url class, but an undocumented change to the IPS Dispatcher class. After installing this new version, only if you are running IPS 4.1.14 or newer, you are going to have to change the 3 URLs you use to integrate in your client application (such as Rocket.Chat). Previously the URL had the form: https://sitename.com/applications/oauth2server/interface/authorize.php Now they have this form: https://sitename.com/applications/oauth2server/interface/oauth/authorize.php The ACP page has been updated with this change. If you can test this out and let me know it works for you, I'll upload this to the Marketplace. oauth2server-1.1.0-beta.tar
  8. Hi @RevengeFNF, thanks for the heads up. Indeed it's likely that the changes to the Url constructor are at fault. I'll have time to diagnose this later this week. Hopefully I can get a fix made before 4.1.14 is released, but given the new classes it will have to be a non-backwards-compatible release to the integration.
  9. Also, you should be able to change the order of display somewhat by changing the order of the applications in the Applications page in the ACP. Try dragging the badges higher in the list - it may, for instance, display about the Steam plugin that way at least.
  10. Hi RDxZen, thanks for purchasing and supporting my little plugin! So glad you like it. The collab badges plugin displays the badges prior to the 'article[itemtype=\'http://schema.org/Answer\'] > aside.ipsComment_author.cAuthorPane.ipsColumn.ipsColumn_medium > ul.cAuthorPane_info.ipsList_reset element in the HTML template. It is set to add to the inside of that element, at the end of the element. If you want to change the element in which this is displayed, you'll need to either customize the theme to change where that element presents (using standard theme editing tools), or you'll have to edit the file ./applications/collabbadges/hooks/badgedisplay.php and change the element selector to something else recognizable in the HTML. If you are able to put your site into developer mode, this is easier by going to the ACP and selecting: System > Applications > Collaboration Badges > Developer Center > Hooks > badgeDisplay.php > pencil icon to edit > postContainer > article[... tab > CSS Selector > Select Element... You'll then need to compile the application using System > Application > Collaboration Badges > Developer : Build Application (XML, etc) and you might want to download it to use for the future. It should only be changing the badgedisplay.php file -- you should be able to just copy the new file over onto any new site and have it work, but I can't promise that will work as I've not tested it. Good luck and let me know how it all works out!
  11. Thanks for the post on your nginx config - hopefully that will help someone else. Rocket.Chat does not pull avatars in its OAuth configuration so that part of the integration won't work for Rocket.Chat. For their other integrations (GitHub, e.g.) the avatar import code is hardcoded as a workaround. I've filed a bug about this upstream. Your other questions are really Rocket.Chat configuration changes - you'll need to file issues with them upstream similarly to lock down the behaviour as you wish. I am not aware of any way to currently achieve what you're trying to do.
  12. {"error":"invalid_client","error_description":"The client id supplied is invalid"} Are you already logged into the forum when this happens or not? If you're already logged in, the ref=### redirect is not working, which means you may have entered the authorization URL into Rocket.Chat incorrectly. Double check that you are using the correct protocol for the URL (http or https, I have tested both) and that the URL entered directly into a browser correctly brings up the authorization page (assuming you are logged in). For example, on my website, when not logged in, I enter https://<mysite.address>/application/oauth2server/interface/authorize.php and I am redirected to a login page. After logging in, I get back the response: {"error":"invalid_client","error_description":"The client id supplied is invalid"} This is what you should be seeing.
  13. Thanks for the update! Still very interested in this. One comment: A IPS4 widget that shows a list of currently streaming streams out of the list would be greatly appreciated, along with just a widget to show a given featured stream. We have a very large community of people and our streamers rotate regularly on and offline. I don't want to have to manually update the "featured" stream multiple times a day. An automatic system to do this would be fantastic.
  14. No, Discord only acts as an OAuth Server itself. It cannot be configured to act as an OAuth client in which the Discord server takes authentication and authorization information from an external source (like IPS4).
  15. I've just released v1.0.1 that fixes a problem with the cleanup task setup (invalid name) and adds a CSRF token check to the authorization form for added security.