My VueJS application relies on a Java backend. This Java backend serves all REST endpoints for providing the data.
When a user performs a checkout the backend responds with a redirect url and redirects the user to that URL. This is done simply like that:
window.location.href = redirectUrl;
As soon as the payment process is finished on the external page the payment provider redirects the user to a return_url which in this case is my VueJS front-end. However the external system sends the return_url in a POST request directly to the front-end which cannot be processed in the as there is no endpoint listening.
What would be an approriate way handling this? As far as I know, VueJS doesn't have any possibility accepting POST requests.
TLDR; It is the responsibility of any external payment gateway system or similar system like OAuth/OpenID to redirect to the calling app via simple browser redirects (via HTTP 302 and 303). So, you should ask/configure external payment provider to follow the standard workflow.
In theory, you should never encounter this problem as POST is typically an Ajax request. Imagine you are on external payment page and when the payment succeeds, external JS is making the POST call and hence the payment page should then take responsibility of redirecting to the appropriate page by reading the reponse.
Now, the second possibility is that payment page is using traditional FORM submission via POST method type and giving back response as JSON or equivalent body. In this case, you should have a server side script (on your ui-server) that would listen for this call and then load the front-end application built with Vue.
If your UI is being served by Java back-end, then it should be simple job of having a Servelet or JSP.
Related
In my application I want to offer users to connect their Google account in order to receive data from the Google Business API.
I pass the API Route as a redirect URL, as I want to catch the code passed and write the token to the database.
Unfortunately when redirecting to the redirect URL and rendering this API Route returns in ERR_SSL_PROTOCOL_ERROR.
How can I correctly work with the API Routes to not render them in the UI, but use them to perform the action.
I solved the problem. I was redirecting to https://localhost:XXXX
Unfortunately there is no https on localhost and hence http://localhost has to be used
I have a relatively large app where there are a lot of user profile pages. I want to make it so that if you share one of the user's profile page it will preview their name and picture on social medias like FB and Twitter (think sharing a Twitch streamer's page on Twitter). I used create-react-app to start the project so I don't have server side rendering or any middleware for pre-rendering tools. Is there another way I can accomplish this?
There two ways you can get this to work
Is the server your files via express server and check for who has the made the request by checking user-agent header from request and if its a bot instead of sending them the usual response you can fetch the required user profile data and use that data to populate the open-graph metatags and return them the HTML with those metatags.
Second way would be to use a network interceptor from the CDN you're using to identify the who is requesting the page (either bot or a person) if its a bot, make a request to your backend to fetch related data and send them the HTML with populated metatags.
Explained approach
Every time a request comes into our server, it comes with a header value user-agent which tells the server who is requesting the resources (human or a bot from Facebook trying to do link preview). Just by comparing a list of known user-agent (so it won't work on all but will work all know platforms and 90% of others.)
Let's say we have something.com where we want the link preview and let's say a request comes for something.com/john. What we will do is check for request that is coming to the server and will check for user-agent property, if its a human it will be redirected to our normal site but if its a bot (so it just wants an HTML for link preview) what we are going to do is since it's our server we can grab the data of akkshay and set the proper metatags inside our HTML and send it back as a response.
So what happens here is whenever a human tries to go for something.com/john he will be redirected to our landing page as he is more concerned about what he sees on his browse but when a bot comes in we will send it HTML response with proper metatags as its the link previews which is the concern for the bot.
This thing can be done on our express server with something like this. But this can also be done infrastructure level.
Objective is to integrate payment gateway to from Stand alone Blazor WebAssembly application. My payment page component has a form that submit directly to the payment gateway like this:
<form action="https://gateway.bank.com" method="POST">
Clicking submit button in the form redirects correctly. After the user complete payment transaction on the bank page, user is redirected back to my app along with response header. Although the redirected url is correct, browser throws 404. Reading more, I found out that since the request is originated from another domain, it gets blocked by CORS. Read many articles about configuring CORS policy for server, but how do I configure it on the client app to allow incoming requests?
Tried the following:
Added Nuget package Microsoft.AspNetCore.Cors
Inserted [DisableCors] attribute on the page
Added CORS policy on Main()
builder.Services.AddCors(options =>
{
options.AddPolicy("Open",
builder => builder.AllowAnyOrigin().AllowAnyHeader());
});
None of these worked though.
Just to ensure the approach is correct I have implemented solution using razor pages with [IgnoreAntiforgeryToken] on page model; it is successful. Help appreciated to find where am I going wrong with WebAssembly. Kindly note that I don't have a server project, only a stand alone WebAssembly project.
If the request is being blocked by CORS, there is nothing you can do on your website to avoid this. CORS is a security mechanism of browsers inspecting the response from a server. If the server does not add the proper CORS header to the response, the browser blocks the response from getting to the site loaded in the browser.
This is an intentional and good (if sometimes frustrating) part of the internet. You would need to contact the bank and request your website be added to the list of allowed origins. They would add your website's URL to the Allow-Access-Allow-Origin header. Because your URL is now part of the cool-kids list, the browser will allow the response to reach your site and will no longer throw a CORS error.
Modern single page applications use routing mechanisms which don't have to rely on fragments or additional url parameters, but simply leverage the url path. How does the browser know when to ask the server for a resource and when to ask the single page application for a spa-page controlled by a router? Is there a browser API which makes it possible to take over the control of url handing which is then taken over by e.g. the vue-router or another routing spa library?
In Vue Router (and I assume other libraries/frameworks are the same) this is achieved through the HTML5 history API (pushState(), replaceState(), and popstate) which allows you to manipulate the browser's history but won't cause the browser to reload the page or look for a resource, keeping the UI in sync with the URL.
For example, observe what happens to the address bar when you enter this command in your browser's console
history.pushState({urlPath:'/some/page/on/stackoverflow'},"",'/some/page/on/stackoverflow')
The new URL is even added to your browser's history so if you navigate away from the page and come back to it you'll be directed to the new URL.
Of course all these URLs are non-existent on the server. So to avoid the problem of 404 errors when a user tries to directly access a non-existent resource you'd have to add a fallback route that redirects to your index.html page where your app lives.
Vue Router's HTML5 History Mode
React Router's <BrowserRouter>
How does the browser know when to ask the server for a resource and
when to ask the single page application for a spa-page controlled by a
router?
SPA Frameworks use routing libraries.
Suppose your javascript app is already loaded in the browser. When you navigate to a route that is defined in your routes array, the library prevents an http call to the server and handles it internally in your javascript code. Otherwise the call is forwarded to the server as a GET Http request.
here is an answer that discribes this behaviour with a clear scenario
From Google Developer Console page, it explains the meaning of "Google Redirect URI" is :
Determines where the response is sent. The value of this parameter
must exactly match one of the values registered in the APIs Console
(including the http or https schemes, case, and trailing '/').
Not sure, whether this explanation is same as my think or not:
On my app (web application), it allow user to sign-in via Google (Assume, I registered a Google project with ClientID/secrete configured on my web-app, and on Google COnsole page the redirectURI is "http://bbc.co.uk" ).
After I login to Google successfully by my Google account, my Web-app login page will be redirected to "http://bbc.co.uk" as on Google RedirectURI ?
That last sentence is a bit ambiguous. A better description is:
After I login to my Google Account successfully with my Google
credentials, Google will redirect my browser back to
Redirect URI http://bbc.co.uk that is registered for the web app in the Google > API Console.
Just to be sure: this means that the Redirect URI should be part of your web app. It is not actually Google's Redirect URI but it is the Redirect URI that you've configured in the Google API Console for your web app.
Let me see if i cant explain this in a different way.
What would happen if you didn't have a redirect URI?
If you go to the Developer console and create a Client ID for native application by default the redirect URI
This will redirect the Authentication back to where ever it was request from. In the case of native installed applications this is needed because there is no way to know where the user is that has installed the application.
Lets look at this in action
Request authentication:
https://accounts.google.com/o/oauth2/auth?client_id={clientid}.apps.googleusercontent.com&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code
If you place the above line in a web browser the user will see something like this
Assuming they select ok then they get this displayed back at them.
That is the Authentication code, not to be confused with the access token. This is just the first step. Once your application has the Authentication code it can then exchanged that for a refresh token and a access token. Most client library handle this step internally. You and your users never see this Authentication code.
Back Redirect URI:
In the case if a web application your web application needs to be able to get a hold of that authentication code. Now I probably shouldn't be telling you this but you could just use a native application client in your web application and it will work. Why because the authentication server will just return the Authentication code back to where ever it was that requested it. For security reasons this is probably a bad practice.
So what do you need to place in the redirect uri. It is the file that you have ready to handle this authentication code. Normally its just the same as the login page, but you can have several. Just put each of them on separate lines.
http://localhost/login.php
http://www.daimto.com/login.php
I like to do this because then it works when i am testing locally vs when its up on the server.
I think the wording "Determines where the response is sent" confuses a lot of beginners as it implies that Google will somehow call that URL directly. Then the word "redirect" leads people to confuse the URL with the page of the app that the user will get to once he's authenticated.
http://bbc.co.uk is definitely NOT the redirect URL. A redirect URL would normally look like https://myapp.com/servlet_or_php_that_i_wrote_to_process_tokens.php
Google will "call" servlet_or_php_that_i_wrote_to_process_tokens.php by redirecting the browser to it. Once servlet_or_php_that_i_wrote_to_process_tokens.php as done whatever is needed with the token, it will then issue its own redirect to (say) bbc.co.uk