currently my local account have different domain like "http://tester.company-dev:8080" , when ever i create an account i will get different domain . how will i set the redirect url in setting page in docusign so that it will redirect me to correct domain url . is it possible to pass a parameter to redirect_url something like below :
"http://{domain}.company-dev:8080/ds/callback" and i need to pass the domain value
here domain=tester
I assume you mean the URL for OAuth, mostly used for Auth Code Grant to redirect users back to your app with the code needed to obtain an access token.
You would have to know all the possible URLs and add them to your IK. There's no way to make this dynamic. This is arequirement of OAuth2.0 specification, it's a security issue and you have to have a matching URL. If there's a reason you cannot do that, we can suggest alternate solutions that may involve not using Auth Code Grant and/or some redirect scheme from a fixed URL to one of these dynamic ones.
Related
I created a simple authentication extension that works in conjunction with PluggableAuth for the user to login automatically. Currently, I need two parameters: a username and a token. These parameters are generated by an external system that sends the data by hidden input. I can get the url data and authenticate correctly. But for security reasons I want to pass this data via $_POST and not via $_GET. But I cannot receive this data and store it in the session so that I can retrieve it in my authentication class. Basically, the user receives a link from a wiki page and Pluggableauth does the checks. But I can't find what code I can use to save the post in the session and retrieve it later. Does anyone have any examples of how to do this? Thanks!
Edit: For example, the user needs to go to www.minhawiki.com/something, the external system sends the post data with username and password to this example page, but because of pluggableauth it redirects to Special:UserLogin, then to PluggableAuthLogin and then to my authentication extension. I've tried to get the data on all these redirects but none of them work. The only way that worked to get the data was to direct the post directly to Special:UserLogin but that way I can't redirect to the login page.
I have a REST api written in node which uses HATEOAS. The user is required to have an account before they can access the bulk of it.
They register an account with login details, then login to obtain an access token, and then use that token in order to access any endpoints that aren't register or login.
Issuing a get to the root responds with a directory with available actions.
Q: What is the correct response from register, to tell the client what it can do next (i.e. login)?
register technically creates a new resource on the server so a 201 CREATED and a Location header would seem appopriate. However the login reference isn't the location of the newly created resource.
Should I return 201 Created with a Location pointing to the newly created user (e.g. /myaccount or /users/{id} and then include a login link in the response body?
{
_links: {
self: { href: "what goes here?" },
x:login: { href: "/login" }
}
}
Do I not tell the client at all, and require them to do a get on the application root in order to fetch a list of available endpoints. This should include login anyway. Assuming the client had to do that in the first place to get the register link it should already have login.
Expecting the client already to already have the login link feels uncomfortable as it relies on an assumption of the client's prior activity.
Requiring the client to issue another request to the root directory after registering seems mean, inefficient and unnecessary. If the client has just created a resource it seems only fair that the server should respond with what it can do with it next.
I like to have my api's act no differently than a webpage. If you want the UX of your application to be the user is taken to login after they register, then 302 them from a successful register to the login resource. And upon successful login, 302 to them to the appropriate destination (IE, if they tried to access something with no token, then take them to login, with a destination of the original requested resource). That's and important part to your #3. Having a link off the root that leads to login, but you need to protect all the other links such that they indicate (and link to) a login being required to access the resource. The client app should expect to get this login required response at any time as tokens can (and do) expire at any time.
Following on this, it might make sense to do the JWT as a cookie instead of as an Authorization Header, it would make it a bit easier for the client (they just have to setup a cookie jar)..if the client is say a native mobile app that maintains a single connection setup. If it's server to server, then auth header makes sense. I'd go about supporting both to cover both scenarios.
Continuing on the idea of thinking of the api as a web site. Why have them login after registration at all? Why not have the registering of an account end up with the login token being sent? they just set their user/pass, why make them enter it again? I realize with some more exotic architectures the register service can not perform the login action (perhaps it doesn't have the private key to sign the token), but if it is possible i'd consider it.
If you really want to stick to the 201 header (which is fine, just make sure the docs of your register relationship indicate that), then option 2 is the closest in my opinion. A location header to the URL of the account just created a 201 is pretty standard for creating a user. But, i'd not return what you've supposed there. You're kind of returning a account-created resource (the thing with the login link), but do you really need this custom resource? If you want to give some messaging back to the client (like "Account Created") in that resource then absolutely yes, but you could also just give them back the root resource.
tl;dr; Decide what you want your UX to be and then make your API implement your UX.
Is there a way to include additional request headers in form data, other than action and method? I am hoping to send some authentication credentials cross domain without making the user re-enter their login credentials. ie I want to build an Authentication header directly from form submission.
The domain is SSL enabled, so I considered including credentials in the URL, but as explained here this is a bad idea, as those credentials may be secure over the connection, but can be accessed through the browser by other apps potentially.
Larger Picture
I have access to the cross domain username and password through an AJAX request to the client server (home domain). I want to take those credentials and submit them through a non-AJAX request, so a user can download a document securely without the URL being publicly accessible.
To the specific question, I believe the answer is no - you can't control sending any extra headers from the form itself. There are some other things you can send with a form, but they are not useful to what you want to do: W3 Form Tag Specification
What you could do is do a form POST, which is the standard way to communicate when sessions cookies are out of the question and a query string won't do; just use a hidden field with some sort of token/hash of the credentials. Avoid clear-text of passwords like the plague, and really try to avoid reversible encryption of them too. This is just one of those areas you have to be extra careful to avoid creating an easily exploitable security vulnerability.
But generally speaking it works just fine, and anything that can do an AJAX GET should be able to do an AJAX POST.
I want to set up a project page on GitHub, so that it acts as a live site.
The site would require an API sid & token (both just long strings of text) that, in a self-hosted environment, the user would just add to the config file.
If I host this through GitHub project pages, users will supply their sid/token through a form. The page with the form will need to be served over SSL so that the sid/token aren't transferred as cleartext. The problem is that GitHub project pages don't allow SSL.
So, if I can find another secure way to take input through a form aside from using SSL, then I can host this whole thing a hosted service through GitHub project pages.
The project would be open source, so I don't expect any sort of encoding/hashing scheme to work, since the methods would be public.
The sid/token are being used in curl calls to an API which is sent over SSL. Perhaps there's a way to direct the form input directly to that SSL URL instead of having it go through the non-SSL GitHub project page...
Any ideas?
You can just give the action attribute of the form the HTTPS URL of the target script, if that's possible.
You could also use some kind of Challenge-Response encryption/hashing scheme using Javascript. The algorithm for that would be something like this:
Server generates unique, random token, saves it and sends it to the client along with the form HTML.
On the client side, Javascript intercepts the form submission and hashes the sensitive form data with the server-generated token as a salt.
Server can now check whether the hash is equal to its own calculated hash value
HOWEVER
A man-in-the-middle attacker with the ability to modify traffic (for example through ARP poisening, DHCP or DNS spoofing) could always strip all your client-side protection mechanisms from the served HTML. Have a look at SSLStrip for a tool to rewrite HTTPS URLs to unsecure HTTP URLs on the fly. The challenge-response could be defeated something like this:
Save token sent by the server, remove the Javascript from the HTML form.
As the form submission is not intercepted now, we get the raw input data.
Hash the data using the same algorithm that the Javascript would have performed.
Thank you for all the fish.
You see, an intercepting attacker can probably defeat any defense mechanism you try to make up.
I have a website on Domain A that has a page with an html form that a user can enter a string into, which submits to Domain B.
The form currently contains a hidden input field with a name/value that Domain B uses to "authenticate"/identify Domain A.
Now, I'm primarily a C# coder with minimal web experience and even I know this isn't a secure way to do this.
What is the best way for a form on Domain A to submit to Domain B securely?
Some ways I've considered:
Have Domain B identify Domain A by domain name or IP. I suppose this would be better than a hidden input field, but domain name and IP could be spoofed, correct?
Have Domain A pass authentication credentials (user/pass for example) to Domain B via some other method besides a hidden field. Not sure how.
Edit
Another possibility: Create a private/public key. Have Domain A pass the private key to Domain B who validates using the public key, possibly via HTTPS. Not sure how Domain A would pass the private key without exposing it in the HTML. Ideas?
A hidden input with a value to authenticate the user CAN be a secure method depending on what the value is and how it's generated. You could have Domain A make an AJAX call to Domain B requesting a token which must be submitted along with the form.
This token should only be accepted only once by domain B and should also expire after a certain amount of time.
Finally, you can also send along an identifier for the user. This should be encrypted in some way for transfer. I would suggest either HMAC or public key encryption.
Option 2: Use OpenID ;)
I have done something similar in the past. This method is frowned-upon by most, but it has worked for me:
Define matching users on both domains. Give them both the same password (and you should probably set it to never expire).
Then, when you run your app in Domain A as this user, it will use pass-through authentication to authenticate on Domain B. You'll just need to make sure the user account has proper perms on both domains.