I'm not finding any RestClient method to update its options, what I need to do is for example disable FollowRedirects for certain requests.
How do I do the following but with v107?
client.FollowRedirects = false;
Background: maybe a separate issue but current problem is that RestSharp is not following a redirect URL to Okta from a Location header of a response, it goes to the main Client URL instead. That is why I've decided to disable redirects to try following the redirect manually.
Most if not all of the properties in RestClientOptions are used to configure the HttpMessageHandler instance wrapped by RestClient. As each RestClient instance wraps a single HttpClient (and its handler), those options cannot be changed. It works the same way as configuring HttpClient, where you cannot change the AllowAutoRedirects property of the handler once it's configured.
That's why the documentation suggests using a specifically configured RestClient instance per remote API. Normally, the API uses a single convention and configuration requirement.
I have seen that some authentication endpoints require redirects, but most of the time the RestClient instance used to get the authorization token is not the one used to access the API itself with the retrieved token. So, the solution would be to have a separate instance for that purpose. Normally, it's only used once to get the token, then you can dispose it and reuse the token.
I keep posting the authenticator example from the docs https://restsharp.dev/usage.html#authenticator
Concerning RestSharp not following redirects properly, it's not what RestSharp does as it doesn't compose or execute HTTP calls physically. It just wraps HttpClient.
Related
I am trying to create a session using pre-existing cookie. However, dont seem to find any way to configure micronaut application.
Ideal flow
Browser calls a rest API
Server detects no session (Unauthenticated)
Request is intercepted and login is performed thro' a call to an external system using the passed in cookie.
if success, Request continues to rest resource and return the result
if fail, return 401
I dont seem to find a way to intercept the request and authenticate on the fly.
Tried to work with Session and idToken but not sure if those are right options. Also, tried to override SessionSecurityfilterRejectionHandler without any luck.
I have an xAPI content made by storyline I want for the statement to be sent to a webapp instead of the LRS.
this webapp is developped using laravel, and user should be authenticated with email and password to use it.
what I did to send the statement to this app:
1.in the webapp I created an API endpoint route that use POST method.
2.in the xAPI wrapper I changed the endpoint in the configuration to the route I made in the webapp.
const conf = {
"endpoint":"here I added my api endpoint route of the webapp",
"auth":"Basic " + toBase64(""),
}
now whith any interaction with the content where a statement should be sent the request making cors error like in the picture down, I think this is authentication error, how can I add my authentication credentials to the xAPI wrapper?
Your non-LRS LRS is probably not handling preflight requests which are necessary for CORS handling. Most common LRSs will handle those requests appropriately since they expect to be accessed from additional origins. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests
Also note that you'll likely run into issues unless you also handle state requests.
Additionally unless you are requesting the credentials from the user during runtime then hard coding the credentials into the package isn't a great idea from a security perspective.
I am building a multi-tenant asp.net core app based where tenants are selected by host names. So tenant1.example.com, tenant2.example.com, ..., and so on.
Also, I'm using Google authentication using the default Google auth handler in asp.net core services.AddAuthentication(...).AddGoogle(...)
It's working great, except that Google doesn't support wildcard callback URLs. So every time I add a new tenant, I have to configure my Google app with a new callback URL to reflect the new host: tenant1.example.com/signin-google, tenant2.example.com, ..., and so on.
The asp.net core Google handler lets you specify the callback path, but not the URL. I plan to overwrite the handler to have the callback URL always go to a redirector url hosted on the naked domain, example.com/redirect-google (I'll be careful about open redirects), and have that redirect to the appropriate sub-domain to complete the authentication.
Has anyone done this before? Anyone see a problem with this approach?
You are right that the authentication system does not allow you to further modify the host for the OAuth redirect URI. This is mostly done to make the system host name agnostic, which is a common pattern that is used throughout the framework (basically every URL generation is based on the current context).
As a workaround, what you could do is set up your own authentication handler for the Google scheme. You can actually inherit from the GoogleHandler and override the BuildChallengeUrl. That method is called to actually build the challenge URI of the authentication provider. It gets passed the redirectUrl which is the callback route of the OAuthHandler (the thing you cannot change the host name of).
So by overriding the method, you can simply change the redirectUrl that gets passed and replace it with the general URL that you want to use.
protected override string BuildChallengeUrl(AuthenticationProperties properties, string redirectUri)
{
return base.BuildChallengeUrl(properties, "https://example.com/redirect-google");
}
When you do that, you will just have to replace the GoogleHandler in the DI config:
services.AddTransient<GoogleHandler, ReplacedGoogleHandler>();
Since we updated our project to Swift 2 and Alamofire to version 2.0 we observe the following behavior regarding base auth: When we send a request (no matter what kind of) with authentication set, the request is always sent without authentication header the first time. After the backend answers with status code 401, alamofire adds the authentication header and and resends the request once again. We send the request using the following snipped:
Alamofire.request(request).authenticate(user: Config.serviceAuthUser, password: Config.serviceAuthPassword)
Is there a way to force Alamofire to include the authentiation header in every request? We want to avoid this kind of auth challenge for every request to lower network and server traffic. We had one solution working for iOS8, where we added the auth header in the session config of the shared instance of Alamofires Manager as follows:
Alamofire.Manager.sharedInstance.session.configuration.HTTPAdditionalHeaders = authHeader
But with iOS9 this does not work anymore, since only a copy of the configuration object is returned and modified.
Is there another way to avaoid this auth challenge process and force Alamofire to include the auth header with every request?
Making two requests is how the underlying URL Loading System was designed by Apple. The Alamofire authenticate methods simply allow you to provide the credentials to supply to the challenge if it occurs.
If you want to provide the header directly, the use the headers parameter on the request method. Additionally, you could insert the user:password credentials directly into the URL.
While I was reading about interaction with Amazon S3, I came to know that request authentication with Amazon AWS is done in 2 ways
HTTP Authorization:
Using the HTTP Authorization header is the most common method of providing authentication information
Query string parameters:
Using query parameters to authenticate requests is useful when you want to express a request entirely in a URL. This method is also referred as presigning a URL.
The question is in which situation should I prefer one method over the other. Do these two authentication methods have their own advantages and disadvantages? As a developer, by using query string parameters method I can presign the URL which enables the end users to temporarily access the Amazon S3 resources by entering the presigned URL in the web browser. Can I use HTTP Authorization method to achieve the same thing? If so which method is better to use and what are their respective limitations?
Can I use HTTP Authorization method to achieve the same thing?
Sometimes. The key difference is that, as a developer, you don't always have enough control over the user agent to inject a header. The most obvious example of this is a simple GET request launched by a web browser in response to the user clicking a link. In that situation, you don't have the a ability to inject an Authorization: header for the browser to send ... so pre-signing the URL is all you can do.
Importantly, there's no information in a signed URL that is considered sensitive, so there's no particularly strong motivation to use the header instead of a signed URL. Your AWS Access Key ID is not secret, and your AWS Secret can't be derived from the other elements and the signature in a computationally-feasible time frame, particularly if you use Signature Version 4, which you should. Signature Version 2 is not officially deprecated in older regions, but newer S3 never supported it and likely never will.
When you do control the user agent, such as in back-end server code, adding the header may be preferable, because you don't need to do any manipulation of the URL string you already have in-hand.
The overview in the first AWS page says what the difference is:
Except for POST requests and requests that are signed by using query parameters, all Amazon S3 bucket operations and object operations use the Authorization request header to provide authentication information.
Basically a POST is used for HTML forms (discussed at length in the Mozilla page). You would use forms whenever the request involves passing data to the remote server, versus just checking status. As noted in HTML method Attribute (W3Schools),
Never use GET to send sensitive data! (will be visible in the URL)
as distinguished from POST:
Appends form-data inside the body of the HTTP request (data is not shown is in URL)