I've been reading the whole documentation related to Acrobat API for document sign.
According to documentation after registering an account, one must create an application inside the Admin UI. For that application one receives the Client ID and Secret. Every request has known parameters like redirect uri, response type, scope, state, etc.
I have been not fortunate with the examples in the documentation and what is most important, some colleagues state it is not necessary to create an application and work with client id and secret, that the only thing initially necessary is to get the Authorization token.
I need to be in the right direction, what are the end points for a testing accounts, where to find the shard. The documentation varies and the end points are just examples, not real ones.
The functionalities I must implement are related to get access token, generate embedded document, get document content, etc.
Thanks in advance
Related
I would like to use 'https://webchat.botframework.com/embed/QuizHS?s=YOUR_SECRET_HERE' to integrate it with Web Application.
But, I would like to secure the conversation by passing token to it as Secret key is in querystring, so that no one can copy above link directly and use it in any other application as this data contain confidential data.
This was answered extensively by Dan Driscoll here: https://github.com/Microsoft/BotFramework-WebChat/issues/428
For purposes of this discussion, we're going to treat secrets and
tokens to be the same thing. We can go into detail on those later if
you want. I'll refer to them as "secret/token" for now.
To access a conversation, you need the secret/token and a conversation
ID. These values are sometimes glued together, and are sometimes in
separate variables. Sometimes they're in the URL, and sometimes
they're stored in JavaScript in memory. These are similar to a user
token, stored in a user's cookie.
In all cases, these values are accessible to a user sitting at their
own computer. They can read their own URLs, they can read their own
JavaScript variable state, and they can read their own cookies.
If they send any of this information to someone else, that person can
impersonate them. If my bank emails me a password reset link, and I
share that with someone else, that person can reset my account
password and log in to my account.
Our iFrame uses URLs to pass these parameters, as that's an adequate
level of security in many cases. (Have you ever visited a website,
manually extracted the URL to an iFrame, sent it to someone else, and
expected your session to remain private? Probably not.)
If you want additional security, you can skip the iFrame and send your
own secret/token inside JS or a cookie. Your JS can extract that and
send it to the Web Chat JS object. Once Web Chat has the secret/token,
is exclusively uses HTTP Authorization headers to send those values to
the Direct Line service.
I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.
Many sites with registration that ask email confirmation and sites use tokens in their url.
Why do they use it?
For example in case of email confirmation: why just not use registered user id instead of token?! In case of using it in web pages, i didn't get at all!!
Explanation with real applications would be appreciated!
Thanks in advance!
A token in this context is typically a disposable time-limited random string used for verification. A token of (say) 40 characters can be generated easily [such as sha1(microtime() . rand(1, 10000)))], which isn't guessable by the user and isn't brute-forceable (within reason).
For email verification, a token will be generated and linked with your account ID. When you visit the address containing the token, the account gets activated. Since we've established that a token can't be brute-forced or guessed (within reason), we've just established that a certain user does indeed have the email address they gave us.
If we just used their member number, they could do several things to just guess it, thus bypassing the email check entirely.
When logging in or submitting a form of some kind, the term "token" may be used in a slightly different context - it's still a disposable time-limited random string, but it's used to make sure that the person who submitted the form has just come from the form they tried to submit.
For example, say you log into your online banking. They might have a form to transfer money to another bank account. If you go to www.nastysite.com they might include an iframe that points to <iframe src="http://www.mybank.com/send_money.php?amount=9001&to=Joe">. If your bank don't verify that you were actually on the form, that payment will go through, and you won't be best happy. Even if you are on the form, the chances of the correct token on your form being used in the fake page-load are (almost) nil.
This is called "Cross-Site Request Forgery", or CSRF. For some more reading on CSRF, have a look at this Wikipedia article. Also, I've just got that link after writing this post and seen that they use a very similar example to mine - genuine coincidence haha.
I want to display a user's wall feed and news feed on my site. How can I do this?
Is there any way to pull the feed without having to get an authorization token?
If I need a token, how do I get that?
The proper (I would go so far as to say "required by Facebook's terms and conditions") way to do this would be to get an authorization token, which involves a pop-up div asking the user if they would like to permit your site (application) to access their information.
You can customize the level of access you'd need and they would be prompted only for that. By accepting, you'd be able to access a token within their cookie. Armed with that token and your application ID and your "application secret" you can make requests to the Facebook Graph API for any data you'd like. (You use the application secret to decrypt the user's cookie, from which you obtain the access token to pass to Graph API requests.)
It's not as simple as just scraping their wall and displaying it, you'd be responsible for grabbing the individual pieces of data and organizing the display.
Edit:
In response to your comment, here is a quick tutorial for working with cookies in .NET. A Google search for "ASP .NET cookies" or "VB .NET cookies" will yield much more as well. There is an example (in PHP) here demonstrating how to decrypt the cookie. I haven't found any .NET examples, but the code here is pretty straightforward. The cookie name is "fbs_" + your application ID.
It appears to be a delimited string, so just read in the whole thing in your debugger and see what the value(s) look like. The value you want appears to be called "sig" (but, again, debug to make sure) and it looks like they're using an MD5 hash to obtain it. You can read up on what the md5() function in the PHP code is doing here and it should be easy to find a .NET analogue for that.
Once you have the access token, it's up to you how you want to get the information. I'd recommend doing it all in JavaScript just to offload the whole thing to the client's browser, not to mention that most samples you'll find online (such as in Facebook's API documentation) will be using JavaScript. But if you want to do it all server-side, Facebook's C# SDK will be of some assistance. You basically pass it the token and the Graph API path you want and it returns a JSON object with all the data.
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.