Are there any url redirection services redirecting based on user's os and screen size.
Related
I'm developing a shell based application. At some point I need to get an oauth token. To do so I start a local server, and open a tab in a browser that'll redirect to the local url once the token is obtained. This seems quite standard, for instance here's Okta's story.
I would like the user to automatically come back to the shell once the token is obtained and the tab is closed. Can I do so?
Start a local server from my shell based program, listening on localhost:3001:
const app = express();
app.get('/', (req, res) => {
res.send('<!DOCTYPE html><html><body><script>window.close();</script></body></html>');
server?.close();
token = req.query.token;
});
server = app.listen(3001);
Open a webpage that'll communicate the token back to my local server:
open http://mywebsite.com/auth/redirect_url=localhost:3001
In the local server, respond to any request with window.close(); (see above)
This works fine in term of getting the token in the shell from the browser. However once the above is done, the user is faced with their default browser on the last tab that was opened before the one launched from the shell, instead of the shell.
Can I do the same and yield the focus back to the shell when closing the tab?
You probably would use in-context launch technique to start(navigate to) the oauth login session. After login completed, you can navigate back to your session.
My bash script when runs produce a URL (basically a login URL to azure), wherein the user has to login to Azure account. I want to automate this using expect script so that the URL automatically opens up in the browser.
This is the kind of URL that my shell script produces :
Please log into Microsoft Azure
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ******* to authenticate.
Depending on JS usage on the webpage, you will not be able to login using expect / curl.
You might want to consider using selenium with firefox, which can record a standard login session and replay it later.
You might then fun firefox headless with selenium to login.
We have a custom WebDAV solution using the IT Hit WebDAV server component. For authentication we are using an Identity Server 4 implementation. The authentication flow, from the user's perspective, is roughly as follows:
Users clicks the link to the WebDAV document in the application.
Office (in most of our test cases, Word) is opened.
If this is the first time the user has opened a document (or the cookie has expired) a login dialogue is shown.
The user enters their username and password, hits the login button and if successful the document is opened.
Behind the scenes the flow is similar to the following:
A HEAD request is made to the parent folder of the document e.g. https://webdav.example.com/documents/
The response to this request contains the headers necessary for Office to show the login dialogue. X-FORMS_BASED_AUTH_REQUIRED etc.
Office follows the URL from the value of the X-FORMS_BASED_AUTH_REQUIRED header. e.g. https://identityserver.example.com/connect/authorize?client_id=WebDAV&response_type=code+id_token+token...
This returns a 302 response with a location similar to: https://identityserver.example.com/account/login?returnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3DWebDAV%26response_type%3Dcode%2520id_token%2520token...
Office opens this URL in the dialogue. Once the user enters their credentials and hits login a POST request is made to the login form, this returns a 302 with the location of the Identity Server callback URL e.g. https://identityserver.example.com/connect/authorize/callback?client_id=WebDAV&response_type=code%20id_token%20token...
A GET request is made to this URL which then POSTs the Identity Server info (tokens) to the configured client callback URL e.g. https://webdav.example.com/account/callback.
This is a custom endpoint that stores the Identity Server access token in a cookie (so that Office can use the cookie) and then responds with a 302 with the location of https://webdav.example.com/account/success. This URL is the same one configured in X-FORMS_BASED_AUTH_RETURN_URL header.
Ona Windows client this all works fine. However on a Mac (Mac OS Sierra 10.12.6) and using Office 2016 (16.11.1 (180319)) we see that the 302 response is returned from the https://webdav.example.com/account/callback URL but it's never followed, there's no GET request made to https://webdav.example.com/account/success.
In addition, there are further WebDAV requests made and stepping through the code we can see that the cookie never seems to be set on the Mac despite the code to do that being executed without error.
So, what's going on?
Thanks,
Stuart.
I am trying to login to instagram and approve my app within my OS X app by opening a web view within my OS X app. I've tried both deleting all cookies and using private browsing independently from each other. I don't intercept requests/responses. First, when I try to open auth URL, I get the following (and correct) page both in my app and in Safari:
However, when I enter my username and password, if Safari, my Instagram account opens, redirects to the app correctly e.g. it logs in. When I enter my (obviously, the same) credentials in my app and click Log in, I'm transferred back to the same screen in a redirect loop of about 10 times:
https://instagram.com/accounts/login/?force_classic_login=&next=/oauth/authorize/%3Fclient_id%3DMY_CLIENT_ID_REMOVED_FOR_SECURITY%26redirect_uri%3Dhttp%3A//my.redirect.url.removed.for.security%26response_type%3Dcode
If I try to visit that URL in Safari, I get to the login screen (if not logged in), and I get redirected to the correct URL afterwards.
I've tried entering invalid credentials, I'm getting a different error, so it's not an incorrect username/password issue:
It appears like a cookies/redirection issue. I've removed all delegates just in case they are intercepting with the login mechanism, but no avail.
Why can't I login to Instagram on Cocoa web view while I perfectly can in Safari? I'm on the latest OS X 10.11.1 and Safari 9.0.1.
It was apparently a bug with Instagram's own cookies, which required a cookie storage reset inside the app's cookie container, which I forgot to clear (I cleared Safari's, but it's different from the app's container).
I've added an option to clear cookies on app startup:
NSHTTPCookieStorage *jar = [NSHTTPCookieStorage sharedHTTPCookieStorage];
NSArray *cookies = jar.cookies;
for (NSHTTPCookie *cookie in cookies) {
[jar deleteCookie:cookie];
}
I've invoked this code and the problem went away.
I have just trying to make one sample application, by which I can login in to my website by Windows Live Id OAuth Protocol.
My application (Downloaded one sample available on net) is working fine. It opens the popup where i can supply my credential for windows live Id and then redirect back on the Redirection URL supplied in my account.
I noticed that when i supply live URL (lets say..... myappp.sample.com) it is redirect perfectly. But when i try to put (http://localhost:52254/WebSite9/default.aspx) this is not supported in my account.
(error -> You must enter a valid domain that begins with http:// or https:// - query strings are not allowed. Length is limited to 248 characters.)
My question is that, How can i use to test the whole thing in my local environment. Because it is not redirect back on localhost URL. Only redirection to Live URL.
Is there a way by which I can test the Live Id OAuth with development environment??
East cake. Put in something like:
http://www.anydomain.com/ in the live app page.
Then add that domain to the host file of your machine (or intranet dns or whatever) pointing to 127.0.0.1.
The redirection is just a 302 redirect that happens in the browser.