So this is really weird: But When trying to connect with Asana I get:
Error: invalid_request: The `redirect_uri` parameter does not match a valid url for the application.
I have literally copied and pasted the example from here
I've literally done everything I can do (Ive been researching all day but nothing works - about 6 hours) What Am I doing wrong?
You can use the variant of the special redirect URI, urn:ietf:wg:oauth:2.0:oob:auto (same as the other, just :auto appended to the end) which is intended for apps that drive a browser themselves and can programmatically read out the token and close the window.
But for both of the redirect URIs you are using, the title of the window should read Success <query-string> where that string is the query parameters that would get passed to the redirect. So for the authorization flow it will include code=....
Your app, assuming it controls a browser window, should be able to navigate to the URL, wait for it to load, read out the title, then close the window, all without user intervention (except for the user actually doing the authorization in the browser window, of course).
Related
I have an ASP .Net MVC5 application using Azure AD Authentication. Whenever I enter URL, it takes me for authentication (if not done already) using a URL of this sort.
https://login.microsoftonline.com/[tenantID]/oauth2/v2.0/authorize?
There are 3 questions
Can I say its using OAuth2 ?
If someone enters a url for a page e.g. https://mydomain/Category/View/1, then it goes for auth (which is alright), but then post successful authentication, it should redirect me to the originally requested URL but currently its taking me to the root URL https://mydomain . But subsequent ones, work fine once authenticated.
Currently the auth happens every 1 hr I believe..how can I extend it to every 4 hrs ?
Will be helpful to see your suggestions.
Cheers.
According to your description of point 2, would you like to achieve that, visiting a url -> direct to login page -> redirect to that url? If so, I think this document can help you.
In my opinion, if I wanna a demo app or app just for simple test, just add all possible url to the redirect configuration form. If I need to do an formal app or I need to make it easy to maintain, I use the idea in the above document. I think the centeral thought is creating a specific place to control url redirecting, including judgment, and only need to add this specific url to the redirect configuration in azure portal. If you wanna a sample, may this document will help you.
To point 3, emmm perhaps you can search for some key words like 'azure ad authentication set token lifetime policy', I found several powershell scripts but I haven't tested. If you haven't got the result I will do some test on it next Monday.
So I have a route in routes.rb like:
get "example/:token" => "example#example"
and even though I have config.filter_parameters += [:token] in production.rb, I still get a log output like:
Started GET "/example/fjiaowevnieninr3"
Parameters: {"token"=>"[FILTERED]"}
where as you can see "token" is filtered in the Parameters, but still appears in the URL path. I'd always assumed filtered_parameters would filter it there as well but I guess not. Is there an official way to filter out named route parameters like this from the logs?
In general it depends on why do you need this kind of behaviour. allenbrkn answer is correct you can send it through query string and it will be filtered from the query string. That said there are more things to consider when you are trying to do this.
There are more type of logs
In the production environment you use some webserver like Apache or Nginx, they have their own access logs, in which they log some headers, paths with query strings and so on (it is configurable).
It means that even if you filter out URL token from the rails log, they will probably appear in the webserver access logs.
Also don't forget these parameters can be sent to external services eg. exception tracking or performance tracking softwares.
Things in the URL are public
Tokens in the URL should not be considered as a secret. Your user can see them manipulate them, send the url to anyone or randomly show it to someone.
I think there two main reasons to put the token into the URL
Hard to guess URL
User authorisation
Hard to guess URL
In this case token is always the same. It is not changed with every access of the URL. It can be usually used as an ID of some resource or something.
For example we are using it as public URLs for invoices so we can send just a link to our clients and they can download the PDF from our site and there are some things to help them with the payments. In the URL is some token so they cannot guess the URL and access invoices of other clients. The token is always the same, so they can access the invoice from the email several times. And the URL is still in the rails log and server access log and we are fine with it because we know the tokens anyway - they are part of the invoice ID.
In these cases it also helps you with the debugging. If some exception kicks in or if there is some issue with the resource it will be really hard to find out why.
User authorisation
This is a bit more complicated. When it comes to authorisation you shouldn't put your tokens into the URL. They should always be in the body and filtered out of the log or in the authorisation headers. Unfortunately sometimes you don't have much of a choice if you need to use it during the GET requests eg:
Single sign on (redirect flow)
Password reset
etc
(Of course you can use request body even with GET requests but you are risking to loose the data eg if the user puts in the URL manually etc)
In these cases you should make possible exposition to valid tokens as short as you can:
Always issue new token on demand never reuse same tokens
Work with very short expiration times
Every token should be invalidated immediately after its use
With these rules it should not matter whether they appear in the logs or not.
For example we have single sign on implemented in our application. The valid token is issued only on demand with 1 minute expiration time and it is invalidated immediately when it is used. In this case it can appear in the log because at the time of appearance it is already invalid and useless.
With password reset it can be a bit more complicated you need token to be valid at least tens of minutes probably and it will appear in the log before it is invalidated. But there are probably not too many things you can do about it - btw if someone has some good ideas I will be very happy to read it.
Conclusion
You can filter the tokens from rails logs but they still probably appear in other logs or even other services if you use them. You should work with your tokens in the URL as if they can appear there and make it as safe as possible for you if they do. Rails log is just one piece of puzzle you have to consider.
As far I know, there is no in-built way of filtering the URL like GET /example/[FILTERED]. But you can create your own method to do that.
After a little examining of https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/http/filter_parameters.rb file, I found that filtering params will also filter the query_string of the path.
For example: In your case above, if you make a request to /example/fjiaowevnieninr3?token=fjiaowevnieninr3, the result in logs would be:
Started GET "/example/fjiaowevnieninr3?token=[FILTERED]"
Parameters: {"token"=>"[FILTERED]"}
So I would suggest you to send your token as a query parameter and do something like this:
In your routes add:
get "example/auth" => "example#example"
Then you can make a request like /example/auth?token=123456
You can catch this token in controller with params[:token]
This way your logs will show:
Started GET "/example/auth?token=[FILTERED]"
Parameters: {"token"=>"[FILTERED]"}
Also, config.filter_parameters is moved from config/application.rb to it's own file at config/initializers/filter_parameter_logging.rb file.
Add the token symbol to your config/initializers/filter_parameter_logging.rb:
Rails.application.config.filter_parameters += [:password, :token]
Also, don't forget to restart the server.
I have an ASP.MVC application. There are some sites in the application which are accesible only with certain user permissions. If user doesn't have required permissions I am redirecting to another controller and displaying page with Not authorized message.
When user without permission tries to visit restricted page using a link, browser caches destination. So always after clicking this link user will be redirected to Not Authorized page, even if permissions are granted. Browser skips directly to cached destination.
I have disabled caching on server side but, this doesn't seem to work in this case, any ideas how I can prevent browser from remembering links destination?
Thanks in advance,
Konrad
There's no logical reason for such a behavior to occur. First, check to make sure that the user is authorized like you think they are and that your redirect code is functioning properly (such that it only redirects if indeed the user is unauthorized). Short of that, make sure you're using a temporary redirect, and not redirect permanent. Although the browser shouldn't decide to just cache the resulting page indefinitely either way, it would perhaps have more cause to think it could if you're sending a permanent redirect.
Without seeing your code I'm not entirely sure there isn't something else going on, but here's a thought:
You can programmatically construct a hyperlink in your razor page to build a unique URL each time the page is refreshed. Just tack on a ?token=#uniqueVar onto the end of the url. The token need not be used in any place in your code, but if your uniqueVar is a timestamp or a Guid or something, your URL will be different every time.
Is it possible to run a request command on a set of multipartFile objects for a set of selected files that has been passed to an second action from an initial action that received them from an type file input html tag.
I can access the multipartfile object as a string in the redirected (second) action -
Such as:
form:org.springframework.web.multipart.commons.CommonsMultipartFile#35d79259
But I am unable to run a request command such as request.getFiles - also I cannot cast it as a MultipartFile.
The redirect to intentional - let me explain what I'm trying to do in more detail:
I have a file upload web page with an input form that sends the selected files (multpartFile objects) to the action. Prior to uploading the files from the client I want the user to have a web page where he adds extra data to each file prior to uploading (metadata tags). To do this I was going to redirect to another action that displays a web page with the list of the files (having transferred the params data that contain the files selected from the original web page to the redirected action) and input fields for the user to add tags. In short the redirect is intentional.
I guess the correct way to do this is using js on the original web page - just wanted to see if I could do it this way instead?
-mike
In general redirects use GET, so there's nowhere for the form body and uploaded file(s) to go. POST/UPDATE/DELETE actions make changes, and a redirect is typically an indication that something went wrong, e.g. something mild like a url changed (301/302), or something more serious like an authenticated user trying to access a page they have no permission for, or an unauthenticated user trying to access anything guarded (401/403).
You wouldn't want to pick up where you left off from a lot of scenarios that trigger a redirect (and it wouldn't be practical at all) so it's common to not attempt to do anything with form or file upload data and let the user re-do the action.
I'm recently facing the problem with last request url after login. Normally, everything works properly. But if I proceed following procedure I have troubles:
Open an App in one tab and log in
In this tab I go somewhere where AJAX request to the server are proceeded regularly
Open a new tab with the app (I'm still logged-in)
In this tab I log out
In the mean time the AJAX request from the 1st tab is proceeded automatically
with HTTP 401 (cause I've logged-out)
When I try to log in again in the 2nd tab than I receive the JSON of the AJAX request from the 1st tab because it was the last request.
I would suspect that Spring Security would neglect AJAX request for "last request url". Is it possible to set this somewhere? Or is there any good workaround to this?
Thanks,
Mateo
I don't think there is a general way to distinguish ajax requests from "regular" requests initiated by the user navigating a browser. If you can distinguish them in your application (e.g. by mapping ajax requests to specific urls that can be matched against some patterns), you could easily implement what you are looking for. (EDIT: An easier way to identify ajax requests is suggested by Sérgio in his below comment.)
The component that is responsible to perform redirection after a successful login is SavedRequestAwareAuthenticationSuccessHandler, therefore one possibile way to customize the framework's default behavior is to provide your own AuthenticationSuccessHandler, and inject it into the UsernamePasswordAuthenticationFilter. It should be possible to autowire the RequestCache in your class, and decide if you want to replay the last cached request or just ignore it in case it's known to be an ajax request.