Membership2 Rerouting Awesome Support ticket URL to image

I'm using Awesome Support for customer issue tracking, and I've run in to an instance where M2 is rerouting a ticket URL to an image, then denying access even though that image is set to Everyone.

Ideally, it would behave as it does with all other tickets so far submitted and forward them to the Awesome Support plugin's shortcode output. I have enabled remote support, and will leave a note with the ticket URL in the support section.

  • Anthony G. Cyphers

    Issue
    When a GUID is passed in a URL while Media Protection is enabled, M2 assumes that GUID corresponds to a media item regardless of slug in URL.

    Example of bad URL
    https://example.com/ticket/2143b0cb-1c5a-4a61-b4d0-6a96edb7e6e3/#reply-8474

    Expected Behavior
    Page should show result of Awesome Support ticket shortcode output.

    Replication
    1. Install Awesome Support on a site with M2 and Media Protection enabled.
    2. Set Awesome Support to use GUIDs in post slugs via the "Advanced" section of the plugin's settings.
    3. Create a new ticket.
    4. Edit the database entry for that ticket and set "post_name" to the GUID of a media item (protection state is irrelevant).
    5. In the Awesome Support tickets UI, click the "View" link for that ticket. The result, if admin, is the media item corresponding to the previously selected GUID. The result, otherwise, is the "No Access" PNG.

    Workaround
    If already effected by this, change the URL setting in Awesome Support's "Advanced" section to use Post ID (or anything except GUID), then modify the effected post in the database. You need to change post_name for that entry to the ID of the post.

  • Adam Czajczyk

    Hello Anthony G. Cyphers,

    I hope you're well today and thank you for such a detailed explanation.

    I tried to follow your replication steps but I'm in doubt about the 5th point:

    4. Edit the database entry for that ticket and set "post_name" to the GUID of a media item (protection state is irrelevant).

    I mean, I'm not really sure what do you mean by that. Should I actually edit the "post_name" for that ticket post that I created and simply copy entire value of a "guid" of any image file (so post of "attachment" post type)?

    Another confusion is, why replication here requires editing of a database: is it just because it's easier to demonstrate it this way or are you using some sort of additional code/tool that's editing that?

    Let me also know please, what settings should I choose for the Media Protection add on in Membership 2 Pro or, better yet, please enable support access to the site in question so I could take a look and replicate the configuration. You can enable support access on "WPMU DEV -> Support" page in your site's dashboard by clicking on "Grant support access" button there.

    Looking forward to your replay,
    Adam

  • Adam Czajczyk

    Hi Anthony G. Cyphers,

    thanks for your response and granting access.

    I set Media Protection to the same configuration as on your site and tried to replicate this ones again but I must admit I'm still confused. Let me explain:

    An example ticket link (that you gave) would be

    https://example.com/ticket/2143b0cb-1c5a-4a61-b4d0-6a96edb7e6e3/#reply-8474

    The "post_name" value for such ticket is "2143b0cb-1c5a-4a61-b4d0-6a96edb7e6e3". However, GUID's in WP are by default actually full URL's so on my setup I'd have GUID's like this:

    - for this ticket

    http://example.com/?post_type=ticket&&p=xxxx (where xxxx is actually a post ID)

    - for some "hoodie.jpg" example image

    http://example.com/wp-content/uploads/2018/01/hoodie.jpg

    If I now edit the "post_name" for the ticket, that "post_name" would become

    http://example.com/wp-content/uploads/2018/01/hoodie.jpg

    which results in only one problem: the ticket URL becomes

    http://example.com/ticket/http://example.com/wp-content/uploads/2018/01/hoodie.jpg

    which in turn causes a simple "404 Not found" error on a default setup. Also, the URL is in no way the same as the problematic example URL from your post.

    That being said, I understand that there is an issue but I'm pretty sure that I'm still missing some vital point in replication or that there's something additional/non-standard in your setup. I'd like to clear that up so I'd be sure that I'm doing everything properly and could actually see the issue on my end in order to look for solution. I hope that makes sense

    Best regards,
    Adam

  • Anthony G. Cyphers

    I'm not sure I follow what you're attempting. It seems like you might be over-complicating. Setting the ticket's post_name field to the GUID of a media item, then accessing the ticket using the example URL I provided gives the behavior I explained in my testing, and I did verify the behavior several times before submitting my description above.

    In short, if you can't replicate it with those instructions, then I don't know what to tell you. There may be other site specific factors.

  • Adam Czajczyk

    Hello Anthony!

    I understand your point but following your instruction I wasn't able to replicate this in any way. Furthermore, with a standard WP setup and the configuration of both plugins matching the configuration on your site, there seems to be no way for these GUIDs to ever "overlap". Images/attachments and tickets are of different post type, they got different structure of permalinks and different structure of "native URLs" etc.

    That's why I asked these questions. I realize that it might have sounded like a bit "over-complicating things" but I'm just trying to identify the "loophole" in the process in order to be able to identify the real reason behind it and look for the "cure". I believe that all the steps that you gave me that should let me replicate the issue, would do it but I think there's something specific in it that we're both missing - may it be some option in configuration of any of these plugins, may it be something related to some other plugin, basically anything.

    That being said, since I still cannot replicate this (and I did try again), I'd like to ask you for a little bit help again: could you please actually replicate the issue on your site? I checked the site again a minute ago and currently all the tickets are working fine (I believe you fixed them using the workaround that you mentioned previously). I would like to see it "in action" then.

    Once you create such a ticket, please let me know which one is that and also please provide me with access to the server (to WP install) so I could take a look at WP files and database. I won't make any changes there whatsoever, I'll only take a look at it.

    To provide me with access (and any additional information related to this that you may think of) please send in:

    Subject: "Attn: Adam Czajczyk"

    - Mark to my attention, the subject line should contain only: ATTN: Adam Czajczyk
    - Do not include anything else in the subject line, doing so may delay our response due to how email filtering works.
    - Link back to this thread
    - login URL and admin account login credentials of the site (may be a temporary admin account)
    - Include FTP log-in details (hostname, username & password)
    - Include hosting control panel access details (login address, username & password) - cPanel's usually the control panel used for this, but your provider may use something else; I'll need this for accessing your site's database, preferably via phpMyAdmin; if there's no cPanel access please provide phpMyAdmin access credentials
    - Include any relevant URLs for your site

    Please use our contact form here https://premium.wpmudev.org/contact/#i-have-a-different-question.

    Kind regards,
    Adam

  • Anthony G. Cyphers

    Adam,
    I understand. I have filled out the contact form with all relevant information. My wife read the previous exchange and said I sounded "short" with you. Sorry about that, I didn't mean to be, I sometimes lack necessary tact in interpersonal communications.

    In other news, every time I type your name I have to go back and correct it from "Adama" to "Adam". Which, being a BSG fan, makes me a little more giddy than it should seeing as I'm a grown man.

    Anyway, have a great day.

  • Adam Czajczyk

    Hello Anthony!

    My wife read the previous exchange and said I sounded "short" with you. Sorry about that, I didn't mean to be, I sometimes lack necessary tact in interpersonal communications.

    Don't worry about that, please, everything's fine I know that there's an issue that needs to be solved and I realize how important that is for you so I really understand However, and I'm deeply sorry for that, I'm not a BSG fan at all - Star Trek is my thing

    Anyway, I've responded to your e-mail message. Please check your inbox and reply to me there directly.

    Have a great day!
    Adam