Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Paul Crowdy 35 posts 96 karma points
    23 days ago
    Paul Crowdy
    0

    Changing /Umbraco Directory

    Hi Matt,

    I have Vendr installed on a project where I have changed the /umbraco directory as detailed here https://our.umbraco.com/documentation/reference/security/Security-hardening/

    Everything in Vendr appears to work correctly, apart from the order-edit view, which appears to be targeting /umbraco/backoffice/Vendr/StoresTree/GetMenu.

    Is there a simple way to reference this dynamically in case the backoffice url needs to be changed again in the future?

    Thanks,

    Paul.

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    23 days ago
    Matt Brailsford
    1

    Hey Paul,

    Good spot. I've actually done a quick search and it looks like we have a reference to this in a couple of places actually so I'll need to resolve those too.

    I've raised an issue on our issue tracker for this https://github.com/vendrhub/vendr/issues/290

    Matt

    PS I can probably take a look at these tomorrow 👍

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    22 days ago
    Matt Brailsford
    1

    Just to let you know, I've fixed this locally and will be in the 1.6.0 release we'll be looking push out next week.

  • Paul Crowdy 35 posts 96 karma points
    22 days ago
    Paul Crowdy
    0

    Perfect - Thanks Matt!

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    Hi Matt,

    I have just updated my site to V1.6, and am now having issues with the payment provider integration that I had been developing.

    Prior to this upgrade, the payment provider was successfully posting data to the ProcessCallback method, but now it is attempting to post callbacks to:

    https://public.dev.domain/new-admin-dir/vendr/payment/callback/utrust-checkout/3cad7f72-5113-4ec8-ae0b-795d4922bdca/ORDER-0462-0507-9WG3/efbee3309cdee77405ad1744c59707298fcfff986422f5dd9fb6dc50c50ee916

    The ProcessCallback method is not being fired at all. Is this something to do with this update?

    Thanks,

    Paul.

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    Hi Paul,

    This likely will be related yea as those URL's previously contained /umbraco in them so they have been updated to use the umbraco back office mvc area. Not quite sure why it's not triggering though so let me do some further tests.

    What exactly is the Umbraco.Core.Path app setting set to?

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    "~/hoi-admin-protected"

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    Ok, that should be fine. I was just checking if there was a casing difference as the callback handler does a URL hash comparison to make sure it wasn't tampered with 🤔

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    In terms of the URL not working, do you know if this is a 404 error? or a bad request 400 response? or a 500 error response?

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    Unfortunately not - the only feedback I get from the provider is:

    We failed to deliver a webhook for a successful payment.

    Error details 16 attempts made %{"1" => "closed", "10" => "closed", "11" => "closed", "12" => "closed", "13" => "closed", "14" => "closed", "15" => "closed", "16" => "closed", "2" => "closed", "3" => "closed", "4" => "closed", "5" => "closed", "6" => "closed", "7" => "closed", "8" => "closed", "9" => "closed"}

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    If I attempt to browse the callback URL I get a 400 error.

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    Ok, so if that is the issue then it would suggest the URL hash comparison failed or it couldn't locate a payment provider with that alias

    Just gonna double check the routing is working as expected first

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    Ok, so I've just tested with your exact path config and everything seems to be working as expected. The URL's are being generated with your prefix, and the route handling is correctly triggering to handle the callback.

    The fact that you see a 400 does mean the routing is working, but it's failing some of the checks, which is the hash on the end of the URL has been altered, or it can't find the payment provider with that alias, or it can't find the order with that order id, or the orders payment method id is null

    Could any of these be the case? Is this a fresh order you've created after upgrading? or could it be one that was created prior to the upgrade and so could have some old info affecting any of these?

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    Hmmm,

    It's definitely a new order - I've just cleared everything and put a new one through, still no callback being received.

    Just looking at the system info on my Vendr settings, it is listing the following as the installed payment providers:

    Vendr.Core.Web v1.6.0

    AppCode.dthxs6r v0.0.0

    Vendr.PaymentProviders.Invoicing v1.1.0

    Vendr.PaymentProviders.Stripe v1.2.1

    Vendr.PaymentProviders.Stripe v1.2.1

    Would stripe being there twice be causing an issue?

    The payment method has the following info:

    Id 70880672-f2bd-4e80-8833-9d5b173eae37 Store Id 3c8ebce9-e386-4e91-972a-996836101e27 Payment Provider Alias utrust-checkout

    and the callback url is:

    /hoi-admin-protected/vendr/payment/continue/utrust-checkout/3cad7f72-5113-4ec8-ae0b-795d4922bdca/HOI-0462-0507-9WG3/e3e7a4cb72eaac8171b3d277a27fe1b460fb7d67ff16a7b9b46e31220fdbd47b

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    Hmmm,

    It's definitely a new order - I've just cleared everything and put a new one through, still no callback being received.

    Just looking at the system info on my Vendr settings, it is listing the following as the installed payment providers:

    Vendr.Core.Web v1.6.0

    AppCode.dthxs6r v0.0.0

    Vendr.PaymentProviders.Invoicing v1.1.0

    Vendr.PaymentProviders.Stripe v1.2.1

    Vendr.PaymentProviders.Stripe v1.2.1

    Would stripe being there twice be causing an issue?

    The payment method has the following info:

    Id

    70880672-f2bd-4e80-8833-9d5b173eae37

    Store Id

    3c8ebce9-e386-4e91-972a-996836101e27

    Payment Provider Alias

    utrust-checkout

    and the callback url is:

    /hoi-admin-protected/vendr/payment/continue/utrust-checkout/3cad7f72-5113-4ec8-ae0b-795d4922bdca/HOI-0462-0507-9WG3/e3e7a4cb72eaac8171b3d277a27fe1b460fb7d67ff16a7b9b46e31220fdbd47b

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    And again, if you run call that URL yourself, you are still seeing a 400 bad request response?

    PS No, stripe being listed twice is fine. It's a known bug. Essentially the stripe payment provider has two payment provider instances in it, so it's being shown twice in the list. We just need to call Distinct on that list :)

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    Yes, when I browse that url I get 400 response.

    I have removed the payment method and recreated it, and still the same issue.

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    🤔 I'm not sure what else to suggest atm, other than getting you to zip up the project (removing any personal data) and then I can debug into the method call and see which element is causing the 400

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    I've just had a thought...

        <rule name="Ignore" stopProcessing="true">
          <match url="^(?:hoi-admin-protected/api|hoi-admin-protected/surface)/" />
          <action type="None" />
        </rule>
        <rule name="Allowed IPs" stopProcessing="true">
          <match url="^(?:app_plugins|config|hoi-admin-protected)(?:/|$)" />
          <conditions>
            <add input="{REMOTE_ADDR}" negate="true" pattern="IP1|IP2|etc..." />
          </conditions>
          <action type="AbortRequest" />
        </rule>
    

    Would I be correct in thinking this may be blocking the payment provider?

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    Hmm, quite possible. You might need to add another entry for hoi-admin-protected/vendr

    <rule name="Ignore" stopProcessing="true">
      <match url="^(?:hoi-admin-protected/api|hoi-admin-protected/surface|hoi-admin-protected/vendr)/" />
      <action type="None" />
    </rule>
    

    But given you get a 400 error and not a 404, I am thinking it is actually hitting the route, but, if something in a rewrite rule is messing with the URL, that could be an issue so worth adding that rule.

  • Paul Crowdy 35 posts 96 karma points
    15 days ago
    Paul Crowdy
    0

    That was the issue. Adding the /vendr rule means that the provider can now post the data back and it is working again.

    I guess before the v1.6 upgrade you were posting to /umbraco... which isn't IP restricted on my site, so there was no issue with it being blocked.

    Sorry for wasting your time!! 😬

  • Matt Brailsford 3020 posts 15702 karma points MVP 7x c-trib
    15 days ago
    Matt Brailsford
    0

    Haha, no worries. I'd much rather know if there is a potential issue in Vendr so it can be fixed.

    Just glad it's all now up and running 👍

    Matt

Please Sign in or register to post replies

Write your reply to:

Draft