I am developing an app for shopify. The app will provide pages and functionality for the Shopify Admin area, specifically using App Bridge.
The app bridge URLs look like this:
https://[shop].myshopify.com/admin/apps/[my-app]/[my-path]
When you visit this page it loads shopify header/footer/menu, also an IFrame pointing to [my-path] on my site, for example:
https://example.com/[my-path]
I would like to setup Ajax requests using the same system of URLs. for example I would use the endpoint as follows (I know this one doesn't exist, just an example):
https://[shop].myshopify.com/admin/apps/proxy/[my-app]/[my-path]
Then instead of rendering the IFrame with my URL, Shopify admin would proxy the request, forwarding it to:
https://example.com/[my-path]
Is this possible, or do I have to send the Ajax request directly to my own server? If the later, how is it recommended I do authorisation? Can the HMAC that came in the original request be forwarded to the AJAX request (seems that would be bad, but not sure exactly why), or use a session that I establish on the original request?
You setup an App Proxy in your App. You provide an endpoint in your App for the Proxy. Once this App is installed in a store, you can now call your App from the store itself, to the Proxy. Securely. That is the whole point of the App Proxy.
Related
I have a single ASP.NET MVC app - website and API controllers. I'd like to use Azure API Management to manage these APIs but retain the same URL so that it is seamless for our consumers. We have a custom domain setup on the app service for this web app that is currently used to serve up both the site and APIs(e.g. Website: xyz.com, APIs: xyz.com/api1, xyz.com/api2, etc.). Also we use AAD for auth. and have the redirect URI setup to the custom domain(xyz.com). Everything works great at present.
The issue arises after we configure API Management to expose our APIs and potentially use it as a passthrough. In order to ensure that the URLs remain the same after API Management is introduced we set the custom domain to be on the API Management instance itself and removed it from the app. service. This is how our current setup looks -->
User hits xyz.com and the request proceeds as follows -> Traffic Manager -> APIM(xyz.com) -> App Service(xxx.azurewebsites.net)
After that last point above, AAD auth. should kick in and once it has the access token after successful auth. it should redirect the user and the page should load. But it doesn't. Instead we get a blank page and if we refresh it, then and only then does it proceed to auth. and load the page.
We have tried setting our redirect URI to both the custom domain(xyz.com) as well as the base app service name that Azure generated(xxx.azurewebsites.net).
Directly hitting the API urls specifically(e.g. xyz.com/api1) works fine. It goes through APIM and responds as expected. The only problem is that the website doesn't load as outlined above.
The moment we take APIM out of the equation, and set the custom domain back on the app service again, everything works as expected.
I'm trying to figure out if we've misconfigured our assets for this scenario somehow or if APIM doesn't support pass through for the website in this manner. Any thoughts/suggestions here would be much appreciated!
Wow, that was a lot of text.
Ok, let's see:
Visitors -> Traffic manager -> APIM -> backend (your website) - ok got it.
this is like a common way of using APIM, and it should work. However, maybe your policies are not set up correctly?
Have you built your product/API/Operations? Do you see requests coming from APIM hitting your site? What responses are you getting?
Now, of course, you will need to define and set up APIM (products, APIs, and every operation) to pass it throw to your backend. This means if you (as a visitor) need to list all products, you would need to go through the APIM operation (sed GetProducts ). Your request will be passed through the Inbound policy(adjust and build the request if needed), pass it to the backend( to your website with custom APIs), and the response will be sent back from the backend back to the visitor.
Now to this: to protect your Web API Backend in APIM, you could use OAuth 2.0 authorization with Azure AD:
big picture overview:
Register an application (for your backend) in Azure AD to represent the API
Register another Application (the client) in Azure AD to represent a client app that will call your API
And I guess this is the one for you grant permissions to allow the client app to call the backend app
And, of course, add the validate-jwt policy to validate the OAuth token for every incoming request
Read om on this here https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
I have separate backend and frontend. However, they run on the same server (this may change in the future). The backend serves as an api and is powered by Laravel. Frontend by Nuxt (Vue).
I wish only my Nuxt application could access the api. How can I configure Laravel to only return data if the request comes from a Nuxt application?
I thought about adding a special token to requests, but the user will be able to check what request is coming out and capture the token. Can anyone give me ideas how this can be solved?
You must be knowing about CORS. So in your Laravel Server, allow requests from only the frontend server's domain like this:
Access-Control-Allow-Origin: https://www.example.com
Simplest solution would be to add serverMiddleware in the nuxt project and route all the requests to the "real" api through it. Clients will hit the internal nuxt api and they will not be able to see the actual request made to the real api. There you can also add the token you are talking about for extra layer of security.
I have a Spring Rest webservice which I call from my website (html pages), So anyone can retrieve the webservice URL from source code of a html pages.
Both webservice and website are deployed in the same server (id address: X.Y.Z.T)
My object is to prevent other people to call the rest service without passing by my site
Is there any way to restrict access to the webservice so that it can by called only by the id address X.Y.Z.T (where the website is deployed)?
Or another way?
Thanks for your help!
You can use something like CORS in the browser.
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
But people with crawlers and such (outside the browser) can still grab your site. You can't stop this, even if you add some kind of authentication. People always able to write automatisation for the login and then crawl your site for example.
Maybe this is not possible...
I have one site, we'll call it club.com
And I have another site called store.com
I have control of both domains. club.com is powered by a Django project, and store.com is a shopify site.
If you're a member of club.com, you get a discount on store.com
We want to do it so that integration is seamless. No need to enter your club.com credentials to store.com, we want the page to do that for you.
How do I implement this?
I already tried simply putting an ajax call on store.com pointing to club.com, and it seems to work with one exception: The browser is not sending the proper cookies along with the request, so when club.com gets this ajax request it can't authenticate it.
You should consider OAuth2 to achieve what you need.
I am trying to do some screen scraping accessing a forms authenticated website. I was doing some tests on an asp.net forms authenticated site that I built and it worked just great. When I tried the real site I realized it was using some kind of an Oracle forms authentication (a fiddler showed a call to a dll instead of an html file. I suppose this dll provides the html result). What I see in fiddler is:
https://{domain}/access/oblix/apps/webgate/bin/webgate.dll
The rest of the call seems similar, cookie, user name and password, just like in the regular forms authentication.
Any idea on how to crack this type of request (to a dll instead of an html)?
(By the way, the result I get is some kind of an Oracle error).
With Forms Authentication the webserver issues the client with a cookie that is used to verify the client in future subsequent requests (HTTP Basic and Digest authentication requires the client to post the "WWW-Authorization" header on every request). Are you persisting your cookies between requests?
The file extension of the url is not important to how you make your request.
It sounds like your script needs to make a request identical to the ajax request made by your browser (and shown in fiddler).