I have two different domains/sites, one http and one https. The http site requires login and then users are shown a non-secure page with an iframe that shows content from the https site.
I would like to seamlessly pass login credentials from the http site to the iframe'd https site. I do not want to use jquery. Is it possible to have the iframe use a POST request instead of GET? I would like to encrypt the login info from the http site and POST the encrypted bundle to the https site.
I'm working with php and apache, if it makes a difference.
I found this article on iframe/POST but wasn't sure how to get the form auto-submitted when the http page loads. Maybe that's a line of javascript? Also, while the login page on the http site has a login form, the post-login page that has the iframe on it does not (currently) have a form. Maybe I could make an invisible form to create this POST request?
Thanks!
You can use Javascript like this:
document.getElementById('someId').submit();
Related
I want to provide a simple 'Login' link on my website, but I'm unable to create a valid redirect url.
My link points to my IdentityServer4 /Account/Login page. How can I declare or generate a redirect url to my client website?
I've thought about simply pointing the login link to a page in my website that has to be [Authorize]'d ... which works, it does then forward on to the IdentityServer login page, but seems a dirty hack.
I've also tried to copy verbatim the url to the IdentityServer produced by this method, but not surprised, it fails with a "Correlation Failed" exception.
Here's the URL I am trying to use copied from an [Authorize] page redirect to IdentityServer, with the generated redirect string (separated for readability).
Localhost:44320 - IdentityServer
LocalHost:44390 - Website
https://localhost:44320/Account/Login?ReturnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dadminwebsite%26rediect_uri%3Dhttps%253A%252F%252Flocalhost%253A44390%252Fsignin-oidc%26response_type%3Dcode%2520id_token%26scope%3Dopenid%2520profile%2520address%2520roles%2520authorisationlevel%26response_mode%3Dform_post%26nonce%3D637402012214631946.OTEyMjNlMzMtMWY4NC20OTQyLWE2NmQt2WMzOWUyMWE4NjdkY2E5nWNmZDUtYzc1Ma00MdI3LTkgMjEtMjr3NyA3YzFkYHZl%26state%3DCfDJ8MY7uAeD4GSDitRtFHe5rPR44JW3TF346c95Sa7_TN0hZjLGDaJyTWAFSHKTgouPov4fDyJEJc6FsOkcg1gOSu4MxY7cqu4N11vPi4f0wu-JpnfWQbbTbtasrhyU-zSf45_aLAvURKmvnlvgogfp_dF_Om5vMYdfsGlvVzgJsiRsvOUGxipsv_hMvCpXmx5ecDHmQvn3xiJVKs2vkzIxI64vuKxPYpMvx44MxgkxwSxv1vnxvHxvXFVLvRvXqVXdfXEN6fvSBT08yr-farVUXVsjXVC3ReaF_sHVXC-fYTXVDJJXl5Q2eCVX7VXCGVKJ7XCcelc-ZFUXVCfqOXC0%26x-client-SKU%3DID_NETSTANDARD2_0%26x-client-ver%3D5.3.0.0
I simply want to declare a login link on my website that will allow the user to go to my IdentityServer, authorize then be redirected back to the same website page as before. I thought this would be a 5 minute job... I've searched all the IdentityServer documentation and google'd every permutation I can think of with no luck, any help will be much appreciated.
I have a program that asks the user to type in a URL, and click download. Then the program downloads the webpage.
However, some websites use SSL, and in that case the user has to prefix his URL with https:// for this to work.
The problem is that the user may not know whether the website uses SSL, and may type http://... instead of https://....
Is there some way to send a preliminary message to the website (from vb.net) asking whether the URL should start with https or just http? If there is, I can correct the user URL before attempting to retrieve the web page.
(I should say there it is not enough to use something like this:
request.RequestUri.Scheme - this looks at the URL the user submitted, not the URL coming back from the server, as far as I know)
For websites that uses SSL, usually they will force the request to use HTTPS. That is when you send a request in HTTP, for example, http://www.example.com, the website will send a redirect response with HTTP status code 302 as well as the URL the client side that initiate the request should redirect user to.
So, you can try HTTP first and check the response to see if there is a redirect. So, you will need to handle that in your code.
I am using cloudflare's "flexible ssl" as an intermediary between client and my site.
After setting this up, I went to the browser and tried accessing my site via https:
https://example.com/login
and everything works. I fill in my login info and log in successfully and am not on http://example.com . I manually enter https://example.com/* where * is many other pages and it all works fine.
Now I want to redirect all requests to use the seemingly working https. So i go to my cloudflare account on their website and create a page rule : http://example.com/* to always use https.
Now I go to example.com/login and successfully redirected to https://example.com/login, I fill in my log in information and submit the login form , the page refreshes and I am back to https://example.com/login with an empty login form.
Anyone know what the problem is or how to help troubleshoot?
I am using laravel as a framework for the site and apache as the webserver.
create a page rule : http://example.com/* to always use https
Noted. Be aware that CloudFlare does this by accepting every HTTP request on http://example.com/* and returning a 301 redirect to the equivalent HTTPS request. The browser completes the redirect by sending a GET request to the HTTPS URL.
I fill in my log in information and submit the login form
Check the login form source carefully and check what URL the login form is submitted to. My guess is that the form is submitted to http://example.com/login or something similar. CloudFlare will accept the POST request to http://example.com/login and return a 301 redirect to https://example.com/login -- which your browser will complete as a GET request and hence not sending the login data.
So your best solution is to make sure that your login form POSTs to the correct HTTPS URL not to the HTTP URL.
That's my best guess anyway.
how to help troubleshoot?
Ensure that you are using different log files to distinguish between HTTP and HTTPS requests on your server.
Some other suggestions:
Get a Let's Encrypt SSL certificate and put that on your site so that the communication between CloudFlare and your site is all SSL. https://letsencrypt.org/
Ensure that HSTS is turned on for all of your HTTPS requests so that the browser will know not to send any requests to any HTTP URLs.
Create a development server where you can test all of this working with HTTPS between the browser and the web server without CloudFlare. Once you've got it all working in HTTPS mode without CloudFlare then you can try it with CloudFlare and you should get essentially the same results. Your problem is with the HTTP -> HTTPS switch, not specifically with CloudFlare.
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
I have an ASP web site that give a warning to visitors with red x (in chrome) and FireFox not verified when they try to login. see the picture
Please advise what it means and what I should do
thanks
When a page is loaded via an HTTPS URL, the browser security model states that all resources referenced by that page should also be HTTPS URLs. Check your page for references to JavaScript, CSS, JPGs, etc. All of them should be using HTTPS when the main page is loaded by HTTPS.
If you have JavaScript that is dynamically loading content with XHR, you need to make sure the URLs you load match the scheme (HTTP or HTTPS) of the main page. This is particularly important for JavaScript that is intended to be reused on multiple HTML pages, some which are loaded via HTTP and some with are loaded via HTTPS.