bfarber

IPS Staff
  • Content count

    154,101
  • Joined

  • Last visited


About bfarber

  • Rank
    RBT-KS
  • Birthday 03/07/1983

Contact Methods

IPS Marketplace

  • Resources Contributor Total file submissions: 9

Profile Information

  • Gender Male
  • Location Southwest VA
  • Interests This is my interests, just for "Rikki" :)

Recent Profile Visitors


737,907 profile views

bfarber's Activity

  1. bfarber added a article in Knowledgebase   

    [4.0.13] Unable to edit themes, forums and other containers in the ACP
    An issue is present in the 4.0.13 release if you attempt to edit Themes, Forums, Categories and other similar containers in the Admin Control Panel if you are running PHP 5.3 on your server.  This is a bug in the 4.0.13 release which is corrected for the next version.
     
    To rectify the problem on your site, please download the attached zip file, extract it, and then upload the contents to your server, overwriting the files already present.
    upload.zip
     
    Important Note: PHP 5.3 is end-of-life by PHP itself for over a year now. If you are still running PHP 5.3 please ask your web host to upgrade. IPS Community Suite 4.1 will not support PHP 5.3.
    • 0 replies
    • 84 views
  2. bfarber added a blog entry in IPS News   

    IP.Board 3.3.x, 3.4.x and IP.Nexus 1.5.9 Security Update
    08-07-2015
    We are releasing a patch for IP.Board 3.3.x and 3.4.x to address a potential cross-site scripting (XSS) issue, and we are releasing a patch for IP.Nexus 1.5.9 to address an issue where license keys may be exposed to unauthorized users. The IP.Nexus patch also includes an updated SagePay payment gateway, required for all users that use Sagepay integration as of July 31, 2015, as well as an update to the Stripe payment gateway to use their "v2" javascript integration.

    It has been brought to our attention that specifically crafted files uploaded as attachments to IP.Board may allow for javascript to execute.  It has also been brought to our attention that specifically crafted URLs may allow for exposure of license keys otherwise kept private throughout IP.Nexus.


    To apply the patch
    Simply download the attached zip for your IP.Board version and upload the files to your forum server.
     
    IP.Nexus 1.5.x:
    nexus_patch_08072015.zip
     
    IP.Board 3.4.x:
    board34x_patch_08072015.zip
     
    IP.Board 3.3.x:
    board33x_patch_08072015.zip


    If you are an IPS Community in the Cloud client running IP.Board 3.3 or above, no further action is necessary as we have already automatically patched your account. If you are using a version older than IP.Board 3.3, you should contact support to upgrade.

    If you install or upgrade to IP.Board 3.4.8 or IP.Nexus 1.5.9 after the date and time of this post, no further action is necessary as we have already updated the main download zips.
     
    We would like to thank ESET for reporting the IP.Board XSS issue to us, and we would like to thank user "vekmor" for reporting the IP.Nexus license key exposure issue to us.
    • 0 comments
  3. bfarber added a release in Release Notes   

    4.0.13
    This release primarily focuses on stability with many bug fixes from both tickets and the bug tracker. In addition to dozens of fixes, important items include:
    When unflagging a member as a spammer, if any tasks are still queued to delete or hide the member's content the tasks will be cancelled.  This is useful if you flag a user as a spammer and then immediately change your mind and unflag the member.NO_STEP issue during upgrade should now be resolvedLists were not rebuilding correctly coming from 3.4.xChanged rebuild routines to not use internal embeds as it represents a change from the way content looked pre-upgradeThere were some infinite redirect issues in some cases when Pages was used, particularly when the gateway file was usedFixed an issue related to core_cache and the task not running
    • 0 replies
    • 194 views
  4. bfarber added a post in a topic v4 downloads is useless for anything but basic use.   

    If we displayed this in the 'Download Statistics' widget, would that accomplish what you are after?  We presently show the total files count and the latest file in the widget.
     
    Indeed, we have determined that the default page most users prefer is the more social page, however there is still a full category listing fallback.
    https://community.invisionpower.com/files/categories/
    One solution might be to remove the application tab in the Applications area of the ACP, and then use Pages to point directly to this URL (instead of just to the root of the application) so that the default landing page users will see is the categories page.
     
    Can you clarify what you mean?
     
    If there are files pending approval, they will still be listed in the category, however the preferred method of managing content pending approval is through the moderator control panel (click your name at the top right, then Moderator CP).  You can manage all content pending approval, as well as content that has been reported, from this one place.
     
    We felt this was inconsistent with how the rest of the suite works, and generally speaking the ACP is for managing the site, while you manage the content on the site from the front end.  The latest submitted files are available in several areas (View New Content, Activity Stream, on the homepage of the downloads area), while files that have been reported broken and/or are pending moderator approval are listed in the Moderator CP.
     
    Are you referring to the Moderator CP feature, or something else?
     
    Unless I'm misunderstanding, this feature is present in the Top Downloads widget.
    http://screencast.com/t/ozG6IWTWsdbK
     
  5. bfarber added a gallery image in Member's Gallery   

    12139618.jpg

    In album: Test pictures

    9 images in this album
    • 0 comments
  6. bfarber added a article in System Management   

    Cookies the suite may potentially set
    While some cookies will almost always be set by the Community Suite, there are some cookies that are set only in very specific circumstances.  If you have a need to identify all cookies the Community Suite may set, the following is a list of cookies and their intended purposes.  Note that it is possible to change the cookie prefix in the community suite, so you may have a different prefix than "ips4_".
    ips4_hasJS: This cookie is set by javascript and then later read to determine if javascript is supported in the user agent.ips4_ipsTimezone: This cookie is set by javascript to detect the user's local time zone so that the software can adapt the displaying of times automatically.ips4_IPSSessionFront: This is a session tracking cookie, used to track the user between page clicks.ips4_member_id: This cookie would contain the user's member ID, used to "remember" the user in case their session ends between visits.ips4_pass_hash: This cookie would contain a hash used to validate that the viewing user's member ID was not forged (it is not the actual password hash).ips4_chat_user_id: (Guests only, Chat only) this cookie would track a guest user's unique "user ID" in the chat roomips4_cms_filters: (Pages only) this cookie would track filters set by a user when filtering content in the Pages application.ips4_ipsApprovalQueueSplash: (Moderators only) this cookie would track that a user has acknowledged the splash screen in the Moderator CP so that it is not shown again.ips4_vseThemeId: (Admins only) this cookie tracks which theme you are editing with the Visual Theme Editor (Easy Mode themes)ips4_vle_editor: (Admins only) this cookie tracks that you are using the visual language editor.ips4_vle_keys: (Admins only) this cookie is also used in conjunction with the visual language editor to track your changes.ips4_acpTabs (Admins only) this cookie is used to track your ACP tab preferencesips4_language (Guests only) this cookie is used to track a language preference for a guest if the site has more than one language installed and the guest user chooses a specific language to use.ips4_anon_login: This cookie is used to track a user's anonymous login preference if they choose this option during the login process.ips4_theme: (Guests only) this cookie is used to track a theme preference for a guest if the site has more than one theme installed and the guest user chooses a specific theme to use.ips4_ipbforumpass_XXX: When a forum has a specific password set, this cookie is set once a user logs in to that forum to validate that they have logged in on subsequent page loads.ips4_thumbnailSize: (Gallery only) this cookie tracks what type of table layout to use in Gallery listings (list view, small thumbnails or large thumbnails)ips4_cm_reg: (Commerce only) this cookie is used to track an invoice ID for a guest who is checking out so that we can associate the invoice correctly after the user registers or logs in.ips4_support_order: (Commerce only, Admins only) this cookie is used to track a user's support preferences while using the support system in the ACP to answer tickets.ips4_support_filters: (Commerce only, Admins only) this cookie is used to track a user's support preferences while using the support system in the ACP to answer tickets.ips4_referred_by: (Commerce only) this cookie is used to track referrals in Commerce when one user refers another user to a purchase.ips4_noCache: (Commerce only, Guests only) this cookie is set in order to prevent pages that have been cached from being served to a guest during the checkout process, as the software has the ability to cache guest pages for a configured period of time.ips4_storeView: (Commerce only) this cookie tracks a user's preference for viewing the store on the site, whether to show it in list view or grid view. 
    Be aware that third party addons may set cookies as well, and that third party services integrated with the Suite (such as Google Analytics or Facebook Logins) may also set their own cookies.
    • 0 replies
    • 284 views
  7. bfarber added a gallery image in IPB Community Photos   

    IMG-5946.JPG
    • 0 comments
  8. bfarber added a post in a topic Brandon Farber - Tier III (Advanced Development)   

    Thank you for the positive comments - they're appreciated
     
  9. bfarber added a article in Knowledgebase   

    Attachments and emoticons displaying as broken images in posted content
    Upon upgrading you may find that attached files and emoticons within posted content (such as posts and signatures) are broken.  This issue was caused by a bug in the 4.0.5 and 4.0.5.1 upgrade routines that has since been fixed, however if you upgraded to one of these versions directly you may be affected.
     
    To resolve the issue, please download the attached fiximages.php script.  Upload this file to your suite root directory (where conf_global.php is located) and then visit it in your browser (i.e. your-web-site.com/fiximages.php).  You will need to click a button to reinitiate the task that rebuilds the image URLs.
    Afterwards, you can elect to run the background tasks from your ACP dashboard manually if you wish, or allow them to run in the background.  The URLs to emoticons and images will be updated appropriately.
     
    fiximages.php
    • 0 replies
    • 1,216 views
  10. bfarber added a article in Site Promotion   

    Topics are not included in the sitemap
    You may find that your topics are not being included in the sitemap that the Community Suite automatically generates.  This may be noticed specifically after upgrading from an earlier version of IP.Board, however can also occur after a new installation of the Community Suite if an administrator configures the software appropriately.
    Topics within forums can be excluded from the sitemap by editing the forum and configuring the "Sitemap Priority" to "Do Not Include".

    Topics within these forums will not be included in the sitemap - if all forums are configured this way, then no topic sitemap will be generated.
     
    Only topics within forums that guests are allowed to access will be included in the sitemap.  If you do not allow guests to read topics in any forums (or if you exclude, per the screenshot above, the forums that guests are able to read), then no topics will be included in the sitemap.
     
    If you disable the 'forums' module for guests under the System tab -> Applications -> click on Forums to expand it, then this has the same effect as above: guests will not be able to access the forums and subsequently the topics will not be included in the sitemap.
     
    Finally, you can use the ACP live search to look for 'Sitemap'. If you do not use the Recommended Settings, you are able to exclude individual types of content from the sitemap. From this page, you can configure Topics to include 0 items, or to exclude them from the sitemap.
     
    There are many different ways to exclude topics from being included with the sitemap. Before submitting a ticket if you believe there to be an issue, you should check the above-mentioned things to ensure that topics are not being excluded from a sitemap due to your configured settings.
    • 0 replies
    • 464 views
  11. bfarber added a blog entry in IPS News   

    IP.Board 3.3.x, 3.4.x Security Update
    04-30-2015
    We are releasing a patch for IP.Board 3.3.x and 3.4.x to address three cross-site scripting (XSS) issues.

    It has been brought to our attention that specifically crafted URLs may allow an attacker to adjust another user's ignored user preferences and private message options.


    To apply the patch
    Simply download the attached zip for your IP.Board version and upload the files to your forum server.
     
    IP.Board 3.4.x:
    patch_34x_04272015.zip 
     
    IP.Board 3.3.x:
    patch_33x_04272015.zip


    If you are an IPS Community in the Cloud client running IP.Board 3.3 or above, no further action is necessary as we have already automatically patched your account. If you are using a version older than IP.Board 3.3, you should contact support to upgrade.

    If you install or upgrade to IP.Board 3.4.7 after the date and time of this post, no further action is necessary as we have already updated the main download zips.
     
    We would like to thank rack911labs.com for bringing the private message to our attention.
     
    • 0 comments
  12. bfarber added a article in Advanced Usage   

    Overriding default cookie options
    IPS Community Suite 4.0 intelligently detects the most appropriate values to set cookies for your site effectively and securely.  For most users these default values work perfectly and you will not have a need to override the default settings.  If you find, however, that these default options are not appropriate for your site (for instance, if you are integrating your Community Suite with an external website), then you can override the default detected options through the constants.php file.
     
    If you do not have a constants.php in your site root already, create one with just the following line at the top.  This file can be used to set many different power-user level options (occasionally, some settings in the ACP will have you add to this file as well).
    <?php  
    After this line you can set the following constants to override the default cookie options.  Be aware that you should ONLY set the values you need to set, and leave the rest of the constants commented out.
    //define( 'COOKIE_DOMAIN', '.example.com' ); //define( 'COOKIE_PREFIX', 'prefix_' ); //define( 'COOKIE_PATH', '/' ); // If your front end website does not serve over SSL but your community suite does, you may need to set this //define( 'COOKIE_BYPASS_SSLONLY', TRUE ); 
    • 0 replies
    • 413 views
  13. bfarber added a article in Development   

    IPS Connect
    IPS Connect is a cross-domain single sign on and single point of authentication system that allows login credentials to be shared across multiple web applications.  Furthermore, basic member management is also shared across those separate installations allowing you to manage users in one website and have those changes propagate to all of your other websites.  While the IPS Community Suite natively supports IPS Connect with minimal configuration from the administrator, developers can also add IPS Connect integration capabilities to their own web applications as well.  This document outlines how to use IPS Connect within the Community Suite, as well as how to develop both "master" and "slave" IPS Connect applications.
    While all changes propagate to all installations that are connected with IPS Connect, one installation will always act as the "master" and all of the remaining installations in the network act as the "slave".  When any requests that are a part of IPS Connect are made by a slave application, they are always sent to the master application.  The master application is then responsible for calling to all of the slave installations to notify them of any changes they need to be aware of (which means the master application must maintain a database of all slave applications that are connected).  If you have an established site and a new site, the established site should be the master installation, and the new site should be the slave.
    Requests that are propagated with IPS Connect include:
    Logging in: login requests are processed by the master application and credentials are shared across all sites in the network.Single sign on: when a user signs in to one application they will be signed in to all other applications, even if those other applications live on different domains.Logging out: When you log out of one application you are logged out of all applications.Registering: When a new user account is added, it is added to all sites in the network.Changing usernames, email addresses and passwords: These requests are propagated to all sites in the network. (Note: you can disable username changes from being shared amongst sites in the Community Suite - see below for details).Banning users: When you ban a user on one site, the user is banned on all sites.Account validation: If a user has registered and you require account validation, that user will be required to validate their account before they can access any site in the network as a fully registered user.Account deletion: If a user is deleted, they will be deleted on all sites across the network.Account merges: If two user accounts are merged, the merge will be copied to all sites in the network. 
    TIP: You can disable username changes from propagating to all sites within a network.  This can be useful when you want to share login credentials amongst all of your sites, but want user accounts to otherwise appear to be separate.  To do this with the Community Suite you must create a file called constants.php in your root directory (where index.php is), or edit the existing one if it already exists. Paste the following code into the constants.php file (if you are editing an existing file, omit the opening <?php tag):
    <?php define( 'CONNECT_NOSYNC_NAMES', TRUE ); 
    Warning
    Be aware that IPS Connect in IP.Board 3.x and IPS Connect in the 4.0 Community Suite are not compatible. While we strived to make the upgrade process painless, the need to expand and improve IPS Connect meant that the 3.x API calls could no longer be processed while adding multiple new features to the set of existing features.
     
    Using IPS Connect in the IPS Community Suite
    To use IPS Connect with two or more IPS Community Suite installations, you must first choose which installation will be the master and which installation(s) will be the slave(s).  Visit the Admin Control Panel of the master application and navigate to the System tab -> Login Handlers.  At the top of the page you will see a notice that tells you credentials you must use in order to notify other IPS Community Suite installations that this is the master.
     

     
     
    There is no "setup" required to make a Community Suite installation the master IPS Connect installation.
    To set up slave applications in the network, visit the Admin Control Panel of each slave individually and navigate to the same area (System -> Login Handlers).  Next to the IPS Connect login method, click on the pencil icon.  Here you will be asked for the Master IPS Connect URL and Master IPS Connect Key that you will have retrieved from the master installation previously.  You will also be asked if you wish to accept display names or email addresses for the login identifier, or both, and if you want to allow IPS Connect authentications to provide access to the admin control panel if the local user account is marked as an administrator.
    After providing the required information and saving this form, you should click the "Disabled" badge in order to enable the IPS Connect login handler, and then you should drag-n-drop the IPS Connect handler to the top of the list to make it the primary login method.  This ensures that IPS Connect is checked first before the Community Suite falls back to the local database to validate a login attempt.
    Setting up IPS Connect with your Community Suite is complete at this point.  You can repeat the above steps on any other installations you wish to connect to your network.
     
    Creating "master" IPS Connect applications
    Your master IPS Connect application will be required to accept API calls from slave IPS Connect applications and respond to them accordingly, and to then propagate changes from those calls to any other slaves in the network.  You must supply a unique key for your master application (which can be anything you want but must be unique to this installation) and the URL to the gateway API file that you will create to all slave applications.  The master application secret key should be kept private and never be made public.
    You must create a gateway file that slave applications will call to.  These applications will send requests to your gateway file and will expect a response in JSON format to those requests (except for certain requests which result in redirection as outlined later in this document).  Your master application will need to implement the API requests outlined below, accepting the expected GET parameters and responding with the outlined Response status code and parameters. Finally, the master application will also need to propagate the requests to all slave applications in its network (and thus needs to maintain a database of all slave applications that have connected with it).
    The IPS Community Suite when acting as a master IPS connect application implements a queue system for requests to slave applications.  If a request that should be propagated to a slave fails, it is inserted into a queue and reattempted at a later time.  Any repeated failures are reported to the administrator via an ACP dashboard plugin.  The requests will be automatically reattempted, or you can manually reattempt the requests from the dashboard.

    While this system is not necessary in a master application, it can help to ensure data consistency across an IPS Connect network.  If the master application ignores failures to a slave application, then email changes, name changes, password changes and more may not be propagated if a temporary error occurs.
    Note that as the IPS Connect API is a public API, while the master key is required to communicate with it, you may wish to implement brute force protection against multiple subsequent login requests. This can help protect against brute force attempts made against slave applications that do not natively support such protection.
    If a slave application no longer wishes to communicate with a master application, it should respond with a status of DISABLED when a request is propagated to it.  If this happens, the master application should disassociate the slave application and cease sending further requests to it.
     
    Creating "slave" IPS Connect applications
    Slave IPS Connect applications will need to send requests for specific actions via an HTTP REST API call to the IPS Connect master installation.  This means that you will need to obtain the URL and API key from your IPS Connect master installation and supply this to your slave application, and then when a user attempts to perform one of the actions outlined at the top of this article your login routines should make API calls to the master application in order to perform and validate those actions.  Be aware: Some requests result in redirecting the user to one or more websites before returning the user to a URL you supply.  See the crossLogin method outlined below for an example. For most requests, however, you will receive a JSON response which will need to be decoded and examined.
    If you issue a login request, for instance, you will receive a response with a status code and then some additional information such as the email address, username and unique ID on the network.  Most slave applications will then create a local user record with this data if the user account does not exist, or update the local user record if the account does exist (using the unique ID to match up user accounts if possible, or falling back to matching accounts by email address).  This is not, however, a requirement.
    Note: After making a login request to the master installation, an IPS Connect slave should then call the crossLogin request at the master installation in order to ensure the user is logged in to all websites in the IPS Connect network.  This method will result in the user being redirected to all installations in the network, and then finally back to a URL supplied by the local slave application.
    All account changes must be sent to the master installation to ensure data consistency across the network.  If a user changes their email address and this account change is not sent to the master application, for instance, the user will no longer be able to login correctly on other sites in the network.
    Additionally, all slave applications must accept the same requests and respond accordingly just as the master would, as the master application must propagate requests to each slave in the network.  For instance, consider the following work flow:
    User changes their email address on SLAVE 1.  SLAVE 1 sends this request to the MASTER.  The MASTER, in turn, sends the request to SLAVE 2 and then to SLAVE 3.  In this case, even though SLAVE 2 and SLAVE 3 are slave applications, they must accept the same requests the master accepted in order to allow them to update their local databases.
     
    API Request Details
    Master IPS Connect applications will need to accept the following requests and respond accordingly with the response parameters outlined for each request.  It will also need to propagate the requests to each slave in its network, differentiating the requests with a "slaveCall=1" request parameter. Slave IPS Connect applications will need to call the following API endpoints against the master IPS Connect installation it is communicating with, and additionally accept the same API request calls (differentiated with a slaveCall=1) in order to accept and make changes to the local database when changes are made at a remote website in the Connect network.
     
    The following GET request parameters will always be included:
    do: This is the action to perform, as outlined below.key: This is the secure key and should be validated to ensure it matches the secure key supplied to the slave application.url: This is the URL to the slave application.Other GET request parameters will be sent and will vary depending upon the request.  All requests from the master installation to slave installations will also include
    slaveCall: Always set to '1', this allows the slave application to know that the request is coming from a master application and is intended to result in the local database being updated.Important Note: If 'id' is passed in the request to make a change to a specific user account, the 'key' value will be an MD5 hash of the master application's key concatenated with the id.  For instance
    $key = md5( $masterKey . $id ); 
    All responses will include a 'status' key in the JSON response. Some responses may include additional information.  You should verify the 'status' response is SUCCESS to ensure the action completed successfully.  Invalid requests will have a status of INVALID_ACTION. Slave applications that no longer wish to be a part of the network (i.e. if IPS Connect is disabled at this installation) should respond with a status of DISABLED.
    Example:
    print json_encode( array( 'status' => 'SUCCESS' ) ); exit; 
    Method: verifySettings
    This method is intended to allow a slave application to verify the settings of the master (i.e. when the master key is first provided) and to "register" with the master installation.  This allows the master installation to propagate requests to slave applications later.
    GET parameters:
    ourKey: [Required] This is a unique key associated with the slaveResponse status codes:
    SUCCESSResponse parameters: None
     
    Method: fetchSalt
    Call this method in order to fetch a user's password salt - necessary for allowing the local application to hash the user's credentials properly before sending them to the master.
    GET parameters:
    idType: [Required] What type of ID is being passed (a value of 1 indicates the id is a display name, a value of 2 indicates the id is an email address and a value of 3 indicates the value could be either a display name OR an email address)id: [Required] The user IDResponse status codes:
    SUCCESSREQUEST_MISSING_DATA: This indicates either idType or id was not providedACCOUNT_NOT_FOUND: No account was found based on the supplied valueResponse parameters:
    pass_salt: The salt applied to the password when hashing it 
    Method: login
    This method authenticates a user and logs the user into all applications on the IPS Connect network.
    GET parameters:
    idType: [Required] What type of ID is being passed (a value of 1 indicates the id is a display name, a value of 2 indicates the id is an email address and a value of 3 indicates the value could be either a display name OR an email address)id: [Required] The user IDpassword: [Required] The encrypted passwordNOTE:
    The 'password' parameter must be encrypted in the same manner as the IPS Community Suite.  A request should first be sent to fetch the user's salt (see fetchSalt above), and then the password should be hashed in the following manner:
    /* $password is the raw password and $salt is the salt returned from fetchSalt */ crypt( $password, '$2a$13$' . $salt );
    $2a$13$ refers to the salt prefix and a pre-determined cost factor that should not be altered.
     
    Response status codes:
    SUCCESSREQUEST_MISSING_DATA: This indicates either idType or id was not providedWRONG_AUTH: This indicates that the provided credentials could not be authenticated.  This may mean that no account exists with the id provided or that the password is not valid.Response parameters:
    connect_status: VALIDATING if the account is still validating or SUCCESS otherwiseemail: The member's email addressname: The member's display nameconnect_id: The member's unique integer ID on the master installationconnect_revalidate_url: If the member is VALIDATING, the URL that any slave application's should send the user to in order to complete their validation 
    Method: crossLogin
    When a user logs in to a slave application successfully, they will be redirected to the crossLogin method of the master application in order to be logged in to it and all other slave applications on the network.  This is necessary to work around cross-domain cookie restrictions.  The master install will need to redirect the user to each slave's crossLogin method, and will also need to log the user in to the master application, before returning the user to the originating URL (the original slave application the user logged in to).
    GET parameters:
    id: The member's unique integer ID on the master installationreturnTo: a URL to return the user to once the user has been logged on.NOTE:
    When the master application redirects the user to slave applications to log the user on, the returnTo URL should be compared to the url parameter in order to ensure the user is not sent to the originating slave.  When sending the user to another slave in the network, the returnTo parameter should be set to the master URL.  Further, the master application should set a 'slaveCall' parameter to 1 when calling slave applications to prevent them from performing extra work (this allows slave applications to know that the request is from the master and to perform specific duties).
    Response status codes: None, the user will be redirected to the returnTo URL
    Response parameters: None
     
    Method: logout
    API calls to the logout method are designed to log the user out of the master application as well as all of the slave installations.
    GET parameters:
    returnTo: The URL to return the user to once they have been logged outid: The member's unique integer ID on the master installationNOTE:
    Much like the crossLogin method, the logout method should redirect the user to all slave applications to log the user out and then log the user out of the master application before returning the user to the originating installation.  slaveCall is passed in the URL when the master calls slave applications to differentiate requests between master and slave applications.
    Response status codes: None, the user will be redirected to the returnTo URL
    Response parameters: None
     
    Method: register
    Register the user on all installations in the Connect network
    GET parameters:
    name: The member's nameemail: The member's email addresspass_hash: The member's password hashpass_salt: The member's password saltrevalidateUrl: The URL to send the user to if they are validating and attempt to login to any other site in the connect networkNOTE:
    The 'pass_hash' parameter must be encrypted in the same manner as the IPS Community Suite.  The password should be hashed in the following manner:
    /* $password is the raw password and $salt is the salt returned from fetchSalt */ crypt( $password, '$2a$13$' . $salt );Response status codes:
    SUCCESSREQUEST_MISSING_DATA: This indicates email, name, pass_salt or pass_hash was not passedResponse parameters:
    connect_id: The member's unique integer ID on the connect network 
    Method: validate
    Call this method in order to mark a user's account as validated. If a user account is marked as awaiting validation and the user validates, this should be called to ensure the user account is marked as validated across the entire network.
    GET parameters:
    id: [Required] The unique user ID of the user accountResponse status codes:
    SUCCESSResponse parameters: None
     
    Method: delete
    Call this method in order to delete a user account. THERE IS NO UNDOING THIS ACTION.
    GET parameters:
    id: [Required] The unique user ID of the user accountResponse status codes:
    SUCCESSResponse parameters: None
     
    Method: ban
    Call this method in order to ban or unban a user account
    GET parameters:
    id: [Required] The unique user ID of the user accountstatus: [Required] A value of 1 will ban the user account while a value of 0 will unban the user accountResponse status codes:
    SUCCESSResponse parameters: None
     
    Method: merge
    Call this method in order to merge two distinct user accounts into one. THERE IS NO UNDOING THIS ACTION.
    GET parameters:
    id: [Required] The unique user ID of the account you wish to keepremote: [Required] The unique user ID of the account you wish to removeResponse status codes:
    SUCCESSResponse parameters: None
     
    Method: checkEmail
    Call this method in order to check if an email exists at the master application. This can be useful to prevent a user who has already registered elsewhere on the Connect network from registering again on a local site, when they should instead login.
    GET parameters:
    email: [Required] The email address to checkResponse status codes:
    SUCCESSResponse parameters:
    used: 1 if the email address is in use or 0 if not 
    Method: checkName
    Call this method in order to check if a username exists at the master application. This can be useful to prevent a user who has already registered elsewhere on the Connect network from registering again on a local site, when they should instead login. It is not necessary to enforce uniqueness of display names in your application if your application has a need to allow multiple user accounts with the same display name to exist, however you should never allow logging in by 'display name' if this is the case.
    GET parameters:
    name: [Required] The name to checkResponse status codes:
    SUCCESSResponse parameters:
    used: 1 if the name is in use or 0 if not 
    Method: changeEmail
    This method is called when an existing user's email address should be updated to a new value.
    GET parameters:
    email: [Required] The new email address to useid: [Required] Unique user ID provided by the master application to a previous login or registration callResponse status codes:
    SUCCESSREQUEST_MISSING_DATA: The new email address to use was not suppliedEMAIL_IN_USE: The new email address is already being used by another accountResponse parameters: None
     
    Method: changePassword
    This method is called when a user has updated their password
    GET parameters:
    pass_salt: [Required] Password saltpass_hash: [Required] Password hashid: [Required] Unique user ID provided by the master application to a previous login or registration callNOTE:
    The 'pass_hash' parameter must be encrypted in the same manner as the IPS Community Suite.  The password should be hashed in the following manner:
    /* $password is the raw password and $salt is the salt to be passed with pass_salt */ crypt( $password, '$2a$13$' . $salt );Response status codes:
    SUCCESSREQUEST_MISSING_DATA: The password salt or password hash was not suppliedResponse parameters: None
     
    Method: changeName
    This method is called when an existing user has changed their display name at a local installation
    TIP: You can disable username changes from propagating to all sites within a network.  This can be useful when you want to share login credentials amongst all of your sites, but want user accounts to otherwise appear to be separate.  To do this with the Community Suite you must create a file called constants.php in your root directory (where index.php is), or edit the existing one if it already exists. Paste the following code into the constants.php file (if you are editing an existing file, omit the opening <?php tag):
    <?php define( 'CONNECT_NOSYNC_NAMES', TRUE );If this is done on a slave IPS Community Suite application, that slave (only) will ignore username change requests and will not send username changes to the master application.  If the above constant is set on a master IPS Community Suite application, username change requests will not be propagated to any slaves in the network. You should carefully consider your intentions if you decide to make the change above.
    GET parameters:
    name: [Required] The new name to useid: [Required] Unique user ID provided by the master application to a previous login or registration callResponse status codes:
    SUCCESSREQUEST_MISSING_DATA: The new name to use was not suppliedUSERNAME_IN_USE: The new name is already being used by another accountResponse parameters: None
     
    Plugging in to your existing master application
    If you are using IPS Community Suite as a master application and wish to extend or change its functionality, you can easily do so without having to edit any PHP files, ensuring your customizations are retained through future upgrades.  The master IPS Connect gateway with the IPS Community Suite is found at /applications/core/interface/ipsconnect/ipsconnect.php.  You can create a new file in this same location called "custom.php" with a class inside this file called ipsConnect_custom, extending ipsConnect.  This file will be automatically loaded if it exists, and the ipsConnect_custom class will be instantiated instead of ipsConnect.  From there, you can override any methods you need to.
    As an extension to this, the following methods can be defined which will be called automatically:
    _postCrossLogin(): Because cross login requests result in redirection instead of returning a response to output in JSON format, this method is supported which allows you to perform any custom actions you require before the redirection occurs._postCrossLogout(): Because logout requests result in redirection instead of returning a response to output in JSON format, this method is supported which allows you to perform any custom actions you require before the redirection occurs.Example:
    <?php // My custom.php file class ipsConnect_custom extends ipsConnect { public function register() { $result = parent::register(); // A user just registered, do something custom now return $result; } protected function _postCrossLogin() { // Do something before the request is redirected to a different site } protected function _postCrossLogout() { // Do something before the request is redirected to a different site } } 
    • 0 replies
    • 1,541 views
  14. bfarber added a post in a topic IP.Content for IPB 4.0   

    The Pages app is the new version of what we previously called IP.Content.
  15. bfarber added a post in a topic Befor buying   

    1) New demos at this time are 4.0.  I'm not sure when you signed up exactly.
    2) What do you want to bridge, specifically.  Logins?  An SSO plugin or an IPS Connect bridge would need to be developed.  It wouldn't be hard to do, but as 4.0 is so new I'm not 100% sure if anyone has released one just yet.
    3) If you cloud host, you'll rest assured knowing the server can fully support our software at all times in a managed environment, while still being able to install any enhancements and themes you may want.
    The following file can be provided to your host to ensure you can use 4.0 on your server environment: http://community.invisionpower.com/files/file/7046-get-ready-for-ips-40/
    4) Yes you can use our software in a subdirectory, but only if it is installed on the same server as your main site (that's true of any software).  If you want to install our software on a different server or use a cloud environment, you'd need a different hostname than the main site for DNS purposes.
    5) The sidebar should work fully on the demo.  I'd recommend emailing sales@invisionpower.com to double check your specific demo if you are having issues.
    6) You can require administrator approval of new registrations with the Community Suite.  It is an option in the ACP.
    7) You can uninstall all of the other apps in the ACP to see what the suite looks like with just the Forums application installed.