Im using a custom form to send to Paypal and take payment. At present I am using the following URLS where the user is directed to, to make payment: https://www.sandbox.paypal.com/cgi-bin/webscr for sandbox and https://www.paypal.com/cgi-bin/webscr for live payments.
I have IPN enabled along with a thank you URL set.
I collect the order info from my ASP net site and when theyre ready i send the transaction to the relevant PP URL (sandbox or Live). The PayPal site is reached, users can make a payment and are returned back to my site.
If i visit https://tlstest.paypal.com/ in a browser from the server where my site is hosted i see PayPal_Connection_OK so this means to me the server is setup but i dont know if any further coding/configuration is required when the form leaves my site to go to paypal to take payments?
I then look in Fiddler and im seeing Tls 1.2 listed on the tunnel to Paypal record.
Do i need to make any further changes to ensure all is setup for TLS 1.2?
Related
I've no backend experience background and I wanted to know if it's possible to set the browser cookies of the customer after he/she fulfills a payment procedure and stripe triggers the checkout session completed event. I'm using NextJs framework and I implemented an API webhook endpoint to listen to that event for some other tasks. Would really appreciate your help.
I've used the Stripe-cli to simulate a checkout being made and installed the cookies npm module to set browser cookies in the backend but that's totally not the way to go since I'm only just testing the webhook endpoint via the stripe commands(trigger, listen).
Not really, since a webhook has nothing to do with the customer and their browser. A webhook is a HTTP request sent by Stripe's server to yours to let up update your backend systems. So if you were to respond back to it with Set-Cookie headers or so on, you're just attempting to set cookies on Stripe's server HTTP client(which won't do anything).
If you want to set cookies on the customer, you might do that for example when they visit the success_url page on your server, which you provided to the CheckoutSession. Note that anyone can visit that URL so you shouldn't set some access/ship a product based only on that. What you might do is set a cookie identifying the customer, and then when they try to access your product or whatever it is they've paid for, you can check your database to see if you've updated it from the Stripe webhook to indicate they've paid.
https://stripe.com/docs/payments/checkout/custom-success-page
https://stripe.com/docs/payments/checkout/fulfill-orders
I need assistance with a company website I'm working on that should be linked up with Azure Active Directory. I have read those Azure Active Directory Docs. Our cloud team have already setup Azure Active Directory on the Azure Portal and when users including myself try to access the page they are brought to a Microsoft Login Page. Our cloud team have fulfilled Step 1 of registering our app on Azure. And this process of logging into Microsoft fulfills Step 2 of Authorization. The problem here is although the users are able to sign in through Azure active directory, once they sign in and come back to the webpage, we are unable to get the code that Azure generates.
This example Authorize link from the docs shows me the correct process for authorization.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=offline_access%20user.read%20mail.read&state=12345
This link will send you to Microsoft Login page and then after you sign in, it will redirect to the specified redirect_url and it will provide the code in the query parameters. I can see it in the URL bar.
My company's app authentication currently doesn't work like this. We are able to have the user sign in and get redirect back to our page. But the redirect_url for our app is www.ourwebsite.azuresites.com/.auth/login/aad/callback I haven't seen this in any other examples and I'm not sure if this is calling a Azure Active Directory specific callback through this endpoint or if somehow the app server should be handling this.
I can see through Chrome Dev Tools when this happens it is sending a post request to www.ourwebsite.azuresites.com/.auth/login/aad/callback and I can see the payload contains the code that I need but the webpage redirects immediately after that request. I have tried to setup a controller with our .Net ASP.NET backend to handle paths from /.auth/login/aad/callback by trying to send a string response back but it doesn't appear that that works.
My Major question is does the url www.ourwebsite.azuresites.com/.auth/login/aad/callback call an azure specific callback function that our app can't interact with? Or is it sending a post request to our server that we should be handling.
After we get this code we will be able to follow the rest of the authentication process.
This picture shows the initial callback call after a user logs into the Microsoft Login page and gets redirect to the www.ourwebsite.azuresites.com/.auth/login/aad/callback I can see in the dev tools that this post request contains the code.
I'm thinking that it's probably something we need to handle on the server especially since it's a post request. Regardless, any help would be appreciated!
I am setting up Fortumo Web SDK payment for my website,
I am putting the url in "To which URL will your payment requests be forwarded to?"
I am using some DB related code here so that it would insert the code in DB and I could check it afterwards,
But when I test the payment it doesn't touch the GET URL and didn't send any request to this URL.
Need Support,
thanks
Finally, I am able to solve the issue, actually the main problem is that fortumo Web SDK works only with HTTPS links and send payment response as a GET Request to the specified link at fortumo configuration.
so no my link starts with https://multanwebtech.com/.......php
I'm using Centrify as my IdP with SAML SSO wordpress plugin to authenticate users on my intranet. This works fine.
However, I would now like to make an POST api call from the intranet back to Centrify to pull some data to display on my wordpress site.
Is it possible to configure Centrify so that it passes something like a .ASPAUTH cookie to the wordpress site so that I can it to make api calls?
If Wordpress is passing the user to Centrify to login (SAML), when the user comes back to Wordpress the .ASPXAUTH token is already set as a cookie in the browser. You cant access it in code, but if you make browser (CORS) calls to Centrify API's, the browser will automatically pass the cookie to Centrify with out you needing to manage it or pass it manually. These calls would need to be made in the browser (javascript), not from the server (php).
You will need to go into your Centrify admin portal, navigate to settings > Authentication > Security Settings > Specify trusted DNS domains for API calls and add the domain of the site that will be calling the Centrify API's. This is to trust the domain for CORS.
An easy test is to add a small amount of code to the browser code that does a simple post to https://tenant.my.centrify.com/security/whoami. No JSON needs to be passed to this call. This will simply respond telling you if we see the user as authenticated.
Please let me know if you have any other questions and do not hesitate to reach out to devsupport#centrify.com.
Thank you,
Nick Gamb
Sr. Manager, Developer Relations and Product Management
Centrify Corporation
I have WordPress based site need to setup sign sign on (Identity Provider is: Ping Identity), I'm use WordPress miniOrange plugin to configure the SSO, when test the configuration, get following error:
Error: Invalid SAML Response Status.
Causes: Identity Provider has sent 'Requester' status code in SAML Response. Please check IdP logs.
Reason: The request could not be performed due to an error on the part of the requester.
Status Message in the SAML Response: Signature required
It (the error) looks like looks like the Identity provider require the SAML request to signed, and ask service provider (WordPress site) to share the public key with Identity provider, but I'm unable to find how to set signed SAML request on miniOrange plugin and don't know which folder to store the private key on WordPress.
Have two questions:
Is WordPress miniOrange plugin support SAML request signature?
How Do I setup it up?
Any other recommended WordPress plugin for SSO?
The answer for your first question is YES miniorange do support SAML request signature and you can send signed request with it but this functionality is not available in free plugin you can go for standard or premium plugin Miniorange Wordpress SAML Plugin.
Now for setting up signed request standard or premium plugin can be done by just checking the signed request the option.
Now answer for your last question is there any other wordpress SSO plugin depends totally on your use case. If you want the plugin for any commercial use I will suggest you to go with miniorange they provide great support and lot of features in premium and standard plan at very low cost. Features available are:--
Basic Attribute Mapping, Widget
Shortcode to add IDP Login Link on your site,St
Auto-Redirect to IDP from login page
Options to select SAML Request binding type
Customized Role Mapping
Custom Attribute Mapping
Store Multiple IdP Certificates
Multi-Site Support
Sub-site specific SSO for Multisite
Multiple IDP's Supported
and various other features you can check it on the wordpress site.
Now second use case if you are looking for free plugin you can check this plugins Wordpress SAML Plugins
Your partner, in the PingFederate console, can disable the requirement for AuthnRequests to be signed. This will be fine as long as your AuthnRequest is telling them to send the Response+Assertion to the same URL as what they have defined in their connection. For example, if your AuthnRequest has an AssertionConsumerServiceURL in it that does not match what the IdP has defined in Ping, then Ping will not honor the request and return a failure.
All that is to say that PingFed at the IdP is configurable for this issue. Have them turn off "Require Authentication Requests to be Signed".