I have a web application that I am trying not to recompile since there is little documentation and the environment is a little sensitive.
With that in mind, all I am trying to do is hijack the authentication mechanism to redirect to one of a couple replacement websites. To that end, there is an authentication service and an authentication controller. The website redirects to /auth/login when the user comes unauthenticated.
In the views folder I have built an alternative /auth/login_new.gsp and from there can authenticate the user and get a redirection back to /auth/redirect.gsp at some frequency but not 100%. That redirect page takes a value from the DB and redirects the user to the correct follow on website. When I run authentication from /auth/login, the site ignores the redirect request to /auth/redirect.gsp.
I had set the show pages for all the different controllers to window.location.href="/auth/redirect.gsp" but I can't get it to go there 100%. I have also reset the layout/domain.gsp file to gut the other functionality of the site and script redirect as well. I was getting errors with duplicate redirect attempts, but now I just go to a dead/gutted homepage...
Any suggestions on how I can dodge the recompile?
Thanks
Leif
Related
I have a Ruby on Rails application which redirects users to the start or login page if they end up at a resource they are not authorized for.
For that, it redirects through a 302 Found.
This does not feel right to me, as for example a successful creation of a resource via POST also returns a 302, with the only difference being that it redirects to the created resource.
On the other hand, it does not seem possible to redirect a user without returning a 30X status code (401/403 in this case).
Am I missing something here, or am I already doing it correctly and this is just the way to go?
Well I'd say that it depends of the context, for an API I'd go for you way, if the user is trying to reach an endpoint without authentication or without enough permissions, I'd return a 401 or 403 respectively.
But for a web application without a separated frontend app, you've no choice to tell to the browser where it has to go next and the only way of doing this is to use redirections (that are only 3xx HTTP codes => https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#redirection_messages).
Wondering if someone can help me understand this peculiar behaviour I am seeing with the AWS ALB redirects.
We have a web application running on EC2 instance which shows three different types of login pages when the correct context path is used like below which works fine:
https:///ucmdb-browser (redirects to the default application login page)
https:///console (redirects to the administration login)
https:///status (redirects to the applicaiton status page)
and
https://<internal-ec2-fqdn/ (Page not found)
So all working as expected.
This Web application is now fronted with AWS ALB so it can be accessed from outside world.
where if someone types:
https://<externalalb-fqdn/ (should redirect to /ucmdb-browser and show the login page)
https://<externalalb-fqdn/ucmdb-browser (should redirect to /ucmdb-browser and show the login page)
https://<externalalb-fqdn/status (should redirect to /status page)
https://<externalalb-fqdn/console (should redirect to admin login page)
https://<externalalb-fqdn/ (should redirect to custom 404 error)
To do this, my settings in AWS listener looks like below:
enter image description here
Now the issue is, whenever I type, any of the URLs, it is being forwarded to 404 page only and unless I change the last default action rule to the actual UCMDB target group.
But that defeats the purpose because one could type any context path whatsoever and it still transfer the request to the application server.
Not sure what wrong I am doing but I have tried all the various combinations I can think of.
Any help is appreciated.
I am trying to create my very first Azure Logic App that simply makes a http post request every hour to a website that has MVC ASP authentication. Whilst setting up the http Logic App action I am using the Basic option to enter the user details.
When it is run, the Logic App keeps failing and returning a 302 (redirect) error; I guess this is because the http post is getting redirected to the account login page.
I have run a test by carrying out a Logic App action to run a http post on a url from the same site that doesn't require user authorisation and it works.
I have also read that I may be able to add configuration to the Logic App action using the Run After rules, but for some reason this option is disabled for my action.
I'd appreciate it if someone with any knowledge in this area, could provide some possible direction.
Thanks.
I am preparing to work on a project where I need to display a dashboard from an online application. Unfortunately, the use of an API is currently not possible. The dashboard can be embedded in an iFrame. However, when it is displayed it will prompt the user viewing the dashboard to login to an account.
I have one paid account to this service. Are there any rails gems to login to the service before the iFrame is processed?
Or would a proxy within my rails app be a better route to go?
Any pointers are appreciated!
Neither a Rails gems nor a proxy within your rails will work and they same have the same limitation.
They are both running on the back-end, server side.
The authentication you need is client side.
Unless you mean proxy the ENTIRE thing, the auth request and all subsequent requests and user interactions with this dashboard. That should work but (see below)
The way authentication works (pretty much universally) is: once you log in to any system, it stores a cookie on your browser and then the browser sends that cookie for every subsequent request.
If you authenticate on the backend, that cookie will be sent to your rails code and will die there, and the users browser will never know about it.
Also - it is not possible to do the auth server side and capture the cookie and then have the user browse the site with their browser directly, for two reasons:
Sometimes auth cookies use information about the browser or HTTP client to encrypt the cookie, so sending the same cookie from a different client wont work
You can not tell a browser to send a cookie to a domain different than your own.
So your options are, off the top of my head right now:
If there is a login page that accepts form submissions from other domains, you could try to simulate a form submission directly to that sites "after login" page. (The page the user gets directed to once they fill up the login form). Any modern web framework as XSRF protection (Cross Site Request Forgery protection) and will disallow this approach for security reasons.
See if the auth this site uses has any kind of OAUTH, Single Sign On (SSO) or similar type of authentication integration that you can do. (Similar to an API, so you may have already explored this option)
Proxy all requests to this site through your server. You will have to rewrite the entire HTML so that all images, CSS, stylesheets, and all other assets are also routed through the proxy or else the URLs are rewritten in the HTML to not be relative. You might hit various walls if a site wasn't designed for this use case. From things like the site using relative URL's for assets that you aren't proxying, the site referencing non-relative URL's causing cross-domain errors, etc. Note its really hard to re-write every single last assets reference, its not only the HTML you're worried about, Javascript can have URL's in it too, and CSS can as well.
You could write a bookmarklet or a browser extension that logs the user into the site.
Have everyone install Lastpass
Have everyone install the TamperMonkey browser extension (and others like it for other browser), and write a small User Script to run custom javascript automatically to log the user in on that site
Scrape that site for the info you need and serve it on your own site.
OK I'm out of ideas. :)
Let's say I have an application that's going to be accessed from completely different domains that all point at the same server*:
example.com, example.net, foobar.com, ...
I have a Devise based authentication system that's worked fine before. However, the goal is now to add HTTPS to the sign in system. The problem is, as it turns out, there is no way to host more than one HTTPS website on the same IP address**. To resolve this problem, I set up the login pages to always POST to https://secure.example.com. As far as I can tell, this is working fine. Devise seems to have no qualm with it. However, the tricky part is that the user now needs to be redirected to foobar.com, which also needs to understand that the user is logged in. I pass the site to return to in a hidden parameter in the login form, and the redirection works fine. I still have no way to inform foobar.com that the user is now logged in.
I've managed to set it up so that, upon being returned to foobar.com, it copies the user's session cookie for secure.example.com into a new cookie for foobar.com. This part is working fine. However, in the Rails console, the web requests for secure.example.com and foobar.com - with the same cookie sent for each - produce two completely different sessions and therefore, it's no wonder Devise acts like the user was never logged in to foobar.com
Does anyone know why this wouldn't work - why two identical web requests (only the domain of the request URI was different - I tried it in Firebug, too) would produce two completely different sessions in a Rails 3 app with different, yet consistent, session ids? More to the point, does anyone know how to MAKE this work?
* assume, for the purposes of this exercise, that this is unavoidable and the sites cannot be hosted all under different subdomains, and that the number of domains required is too great to get a separate IP address for each.
** unless they're subdomains and you have an *.example.com cert, but that's beside the point.
If you're already using Devise, I suggest you try using token authenticatable. You can generate a token for the user in question, redirect them with the token to sign in, and then quickly expire the token after they have signed in.
You could also try rolling your own OAuth provider with doorkeeper.