I am struggling with something and I am not sure if this is possible or not with the current WP7 API. Basically my WP7 App uses WebRequest class to issue web requests to log into a third party website using username and password credentials of the user. I store session state/cookie information in a CookieContainer object so that I can make further requests for data from the web site and this all works fine, pretty standard scenario so far.
But what I would like to do now is offer a link to take the user to the secure area of web site without needing the user to log in again when accessing the site from the phones browser. If I simply call a webbrowsertask it takes me to the website but the browser has no knowledge of the cookies I stored in my app so the web site redirects the user to the log in page. What I need/want to be able to do is provide the CookieContainer object I have stored from my app requests through to the webbrowsertask so that I can go straight to the page I want.
WebBrowserTask webBrowserTask = new WebBrowserTask();
webBrowserTask.URL = "https://www.xxx.com/loginarea";
webBrowserTask.Show();
Any suggestions/thoughts on how I can do this?
Thanks.
I don't think you can get the cookies to the main IE web browser
However, if you were prepared to host the browser control inside your app, then you should be able to inject the cookie values using javascript.
Related
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.
This issue only seems to be affecting Firefox, and then only some users (with no obvious version/security setting differences). We are getting session loss in our Laravel app.
We have a payment integration that uses the iframe Opayo server integration. This opens up the payment form in an iframe in the Laravel app. Payment details are provided, and the payment is successful - including hitting an Opayo webhook to confirm the transaction.
The webhook returns a redirect URL, that Opayo uses to redirect the user (in the iframe naturally). This redirect URL is simply a URL on the same site as the app (i.e. the iframe parent).
At the point that the iframe loads the redirect URL, the site session is immediately killed. Originally, the page at the URL broke out of the iframe (set window.top.location), and also did some ajax calls - I removed both these actions, to confirm they weren't somehow responsible for the session getting nuked.
The site is served over HTTPS with a valid certificate. A session cookie is set to secure, HTTP only, and the same site is 'lax'
What could be causing this behavior?
This is because the iframe is not exactly your page running on your system. So, if the iframe is not on your system, it will not have access to the cookies that are in your application.
If the iframe is from your application, I advise you to use query params in the url of the iframe to pass such necessary information within the iframe. Something like:
<iframe src="https://www.foo.bar?value=1&value_2=2"></iframe>
I am trying to implement custom OAuth login into my Xamarin application.
I am hitting the OAuth API from browser when a Login button is clicked.
It is redirecting to my custom OAuth authentication page and after initial authentication it sends an auth code in the URL of the auth.html from my domain page. I need to read that URL and process further.
My code in the button click :
var apiEndpoint = "https://auth.example.com/oauth2/authorize?response_type=code&client_id=myclientid&redirect_uri=https://example.com/apps/auth.html&state=STATE";
await Browser.OpenAsync("apiEndpoint", BrowserLaunchMode.SystemPreferred);
I need to read the code from the URL when is is returned from my domain redirect uri as below:
https://orion.lexmark.com/winapps/auth.html?code=12358123-2200-4ga6-a806-8f60f5636ac8&state=STATE
I am very new to the xamarin world, any help on this will be appriciated.
The most common way to do mobile OAuth is to use a Private URI Schene URL such as this, which will then invoke the app with the login response when it is returned to the browser:
com.mycompany. myapp:/callback
It is standard to also open the URL via an integrated form of the system browser - a Chrome Custom Tab on Android.
Developers usually also plug in the open source AppAuth libraries to do the tricky work of using OAuth messages correctly. This will be harder in Xamarin though, due to the extra layers.
I would recommend having a look at AppAuth and at least borrowing some ideas from it. My Android AppAuth Blog Post explaims a fast working setup.
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
I've been using Advanced Rest client to test my REST api. Earlier Advanced Rest client used to open as a new tab in chrome. So I could Login into my application in one browser tab and in a new tab I could open Advanced Rest client, call my api's.. test it. Everything was ok.
But now after the new update Advanced Rest client has become a separate app, I can no longer open it in a new tab. So now I when I call my rest api's, I'm getting No session.
How do I add session in the new update of Rest client?
You will need to install this extension (ARC cookie exchange): https://chrome.google.com/webstore/detail/arc-cookie-exchange/apcedakaoficjlofohhcmkkljehnmebp
and enable the Use XHR toggle in the Advanced rest client. It should then work.
It depends on a session type. If this is a cookies based session the app is already supports cookies. They are saved in local database (as user agents would do) and automatically added to the request when the domain and path of the cookie matches the request URL. (domain and path matching algorithm is defined in the spec: https://www.rfc-editor.org/rfc/rfc6265#section-5.1.3).
The app will not accept cookies set in regular Chrome session since Chrome apps do not have access to the Chrome's cookie storage. There's simply no API for this. So session registration must be done in app - not the browser. So if the session is set up after form submission you need to create the request that will send form data as regular form would do and then use the app normally.