The new Oauth2 authorization process seems to work very well. It took a little time to change my class methods to handle it and the other changes to the API, but I have everything working smoothly now. One small problem I haven't figured out yet is how to pick up the redirect request when the user clicks "Deny" on the 2nd part of the login process. I get the redirect fine when "Allow" is clicked, but I get nothing at all on "Deny." My callback URL is something like ht-btz://com.cloud so according to the documentation, I'm supposed to get something like this:
ht-btz://com.cloud??error=access_denied&error_description=The+user+denied+access+to+your+application
I've tried it with a custom, Python-wrapped IE browser that can monitor redirection, and with a custom local URL protocol handler, and neither gets any request to the callback uri. But both pick up exactly what the documentation says on the approval click.
It's not really a showstopper, since the "Deny" click stops everything anyway. But it would be better to handle things gracefully with the callback request. So is this is bug, or am I missing something?
thanks
Mike
This is a confirmed bug on Box's end with non-HTTPS protocols. We're working on a fix and should have it out sometime this week.
Related
I have 2 UI applications (node and ejs server side rendered).
Say
www.example.com and www.abc.com
I redirect user from Application A to Application B using a simple button with href.
Now the Referrer in the Request header is Application A url which is expected.
Also after redirection to Application B. If the user navigates to the child pages, then the referrer is Application B url, which is also expected.
But the problem/issue is that from the child page of Application B, if the user clicks on browser back button then the referrer is Application A url which is not expected. Ideally the referrer should be application B since it's an internal redirection within the application.
This case is tested in Chrome and Firefox both behaves in a similar way.
I have to perform operation based on the right referrer. Please suggest a fix or correct me if my understanding is wrong.
Thanks in advance.
The Back button's function is to restore the previous page to the browser. That page arrived at the browser with its referer set to application A. So if the Back button does anything it's going to give you the old referer. That can't be changed. Because cybercreeps.
Your best bet is to handle the case some other way. For example, you could use session storage to set some kind of browser flag saying you've already seen the first referer.
How can we submit a form without Javascript and not by pressing any buttons?
I need to transfer a content to another file when a function works under certain conditions. Both the files are written in Perl. The pages are loaded in a webserver(same). I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
But there I didn't find any ways to redirect a URL where the values are transmitted in post method. So I came up with the form submission. But the problem is I need to use javascript or make user to press a button to complete the task.
The problem with Js is there some users who disable JS in their browsers.
So using it is not preferable. With the button,
I can't make the user to do that for me.
Is there any other scripting language, which supports such functionality?
There are some conditions that I can't use session
What I did is encryption for identifying the user from knowing what data is transmitted. The receiving page will decrypt it when it is required. But it's not what I needed.
I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
It isn't. If you pass it through the user's browser, then the user can see it.
Is there any other scripting language, which supports such functionality?
No. There is no programming language as well supported in browsers as JavaScript, and none that are harder to disable then JS.
Store the value on the server (you could use a session) and redirect the user with a normal 302 status and Location header. You can pass a session token via cookies or the query string.
You can't make a user do anything, unless you're writing for a browser the equivalent of a trojan.
But secondly, without something on the client side, you can't ensure that you can get information that you didn't have when you sent the page.
You could place some links, and know which links they clicked on by passing it through a central tracking program, but those links wouldn't have anything in them that didn't originate on the server without client script running.
Still, despite that you can entice a user to click on a link more than a simply functional button, in either case you can't get guaranteed new information from them. They can always close the tab, close the browser, or press the back button. This goes back to point #1: you can't make users do anything.
We currently have an implementation that uses boxes API. Our authentication process follows the process outlined here:
http://developers.box.com/get-started/#authenticating
Sometime in the recent past this has stopped working. When we go to the oauth URL (for example, https://www.box.net/api/1.0/auth/rev37d850p6pixlemm5ok8doxj2g77kg), it will initially show the login credentials page, but faster than a user could reasonably enter their credentials the page starts returning "expired ticket". If I immediately go to the token's page after creating it I can reload the page a few times before it goes into the "expired ticket" state. This is clearly not consistent with the expected 10 minute expiry time stated in the documentation.
We've had this authentication working correctly up to now, so it seems like something has changed.
We are investigating. More news once we have some additional information.
New info>> We've identified the bug, and will be pushing a fix this afternoon.
The fix has been rolled out. Please let us know if you are still experiencing any problems with SSO.
Our Android app has the same problem. As far as I investigated it, using get_auth_token API causes the ticket to expire. So you have to make sure the user has successfully logged in BEFORE attempting to get the authentication token (which is not the case with Box SDK for Android). But I don't see a viable way to check whether the user has logged in.
As I am testing out one of the HTML5 features - geolocation for my project,
I realized that users can close the prompt without allowing or denying it,
that defeats the whole purpose of the prompt.
And because in my project I want to dynamically display data to users depending on user's location, this can't be done, simply because without knowing user's response,
it doesn't trigger any of the two callbacks - success / error.
so I started searching to see if there's any solution to this,
and a lot of suggestions to this is to set timeout,
I tried and everything works perfectly.
However, one small flaw here is tho, by the time it hits the timeout expiration,
all the data are already displayed, and when i say all, i mean EVERYTHING,
because there's no location detected.
So I came up with two solutions that might work,
1) create a custom geolocation prompt that forces users to allow/deny location to be shared,
and pass the response to browser to set the location preference
2) pause page-load (stop stuff from being rendered) and wait till it hits the timeout expiration or it gets response from users
Does anyone have any idea how to implement one of these two solutions?
PS: sorry if this isn't unclear to you, i know my english sucks, but I can explain in more details.
Thanks guys!
You shouldn't be able to use a custom Geolocation prompt if your project is browser based, because malicious developers could use the method to trick the user. Also, since the Geolocation API is an asynchronous event, it's going to continue loading the rest of the page while it waits.
What I recommend is to use a conditional statement instead with an else clause. This way, your script functions should only execute after location has been shared, and you have a fall back on what should happen if no geolocation information is provided (which I highly recommend as situations will occur when the data isn't provided).
Example of the conditional statement to check for geolocation information using JS:
if (navigator.geolocation) {
// code to run if there is geolocation information
}
else{
// code to run if no geolocation info is given to the browser
}
I have a form which is posted to an external API. There is a parameter called customer_token which is passed as an input field. It is used for authentication by the API and every customer is assigned one token. The input field is visible in Firefox's Firebug (even though it is a hidden field).
How do I hide it?
Options
Using javascript as I thought initially
I think using javascript to create that input field at the run time before submitting the form and immediately removing the field will work but still the field will appear momentarily. So, even if a person can't manually get it, I am afraid that a crawler or spider (I don't know the exact term - but some automated script) may get the customer token. Is there a better solution for this? After form submission, the same form remains displayed.
Using one-time token concept as suggested by Ikke
I am not sure how it will work? The API needs the correct customer token value to process any request. So, even to generate a one-time token and return, a request with the customer token has to be sent. This way anyone is able to see my customer token value and they can also send a request to get a one-time token and use it. So how does it solve the problem?
Resolved
Check How to post form to my server and then to API, instead of posting directly(for security reasons)?
Thanks,
Sandeepan
This is not possible. Firebug just reads the DOM in it's actual state, so even if it's added in a later stage, it can still be retrieved.
This way of security is called Security through obscurity and is a kind of non-security. You would have to solve it another way, like letting the server do the request in stead.
You let the user submit the form to the server. Then with curl, you make the call to the webservice with the correct user code.
I don't think this is possible I'm afraid.
Firebug will still see the element if it's inserted via Javascript, as it watches the DOM tree. If this input exposes a security vulnerability then it's the job of your server-side code to validate/fix it.
More details on the API might help somebody answer this question in more detail.
I hope this helps