How to overcome embedded authentication prevention of Chrome? - security

In recent versions of the Chrome, embedded authentication has got forbidden so we can't find a way through how to handle these JS authentication popups programmatically.
We want to get a picture from a secured server.
Like:
http://admin:123456#192.0.0.1
Also, the img src of HTML elements didn't work. The server responded 401 not authorized info.
Someone has any ideas?
Thanks in advance,

Perhaps you can add an endpoint to your application which takes the user authentication information ( as in Basic Auth ) through the HTTP Header and then treats the request for the file resource as a GET call and writes back the resource in the response.

Related

Instagram API Matching code was not found or was already used

I am seeing this error from my live server using the Instagram API.
{
"Error":true,
"message":"Matching code was not found or was already used."
}
I have read a few suggestion on here to clear cache but that isn't fixing the issue. I am also unable to submit a support ticket directly on the Instagram site as I am receiving an error message while attempting to submit a ticket.
There are a bunch of developers complaining about the same issue at https://news.ycombinator.com/item?id=13178789. I don't think unchecking "Disable implicit OAuth" fixes the issue as I have already tried that and it didn't work.
The best thing you can do is to submit a report to instagram using your client id to put some pressure on their side to fix this issue.
I have the same issue, I guess it's from Instagram I reported an issue from my client panel in developer > manage clients > Report issue.
You can do they resolve this issue as soon as possible.
There is definitely a problem with the Instagram OAuth flow. The returned authorization code doesn't seem to work for some reason, it's very likely a network related problem that they need to fix on their end.
My theory is that the authorization code generated is not distributed to all Instagram API servers, and if you happen to hit a bad node then you're out of luck.
However, I recently found a solution that doesn't rely on the authorization code. If you use the client-side authentication then you'll be able to retrieve the access token without ever using the authorization code. It's less secure but works great as a temporary fix.
You simply change response_type=code to response_type=token. The token response type will redirect the user back to your website using this URL structure:
http://your-redirect-uri#access_token=ACCESS-TOKEN
I recommend fetching the access token from the URL client-side using JavaScript, and then passing it to an endpoint on your website. E.g. /callback?accesstoken={accessToken}. This is required because the content in the hash is not passed to the server.
Example:
<script>
if (window.location.hash && window.location.hash.indexOf('#access_token=') !== -1) {
var accessToken = window.location.hash.replace('#access_token=', '');
window.location.href = '/callback?accesstoken=' + accessToken;
}
</script>
The code snippet above is copied and slightly modified from the solution at https://news.ycombinator.com/item?id=13178789
You can read more about Instagram client side authentication on https://www.instagram.com/developer/authentication/ under Client-Side (Implicit) Authentication
I just had the same issue. Not sure why, but for me the code returned from oauth/authorize/? had 2 special characters at the end - "#_". After removing these my code worked.
This is due to security restrictions in place on your Instagram app. You can choose to allow it by unchecking "Disable implicit OAuth" for your Instagram app, under the Security tab.

Retrieve BLOGS_UPLOADED_IMAGES in java

I have some java code that retrieves blogs through the REST API's. I am not using the social business toolkit, but we have our own framework for that.
The application works perfectly on an on-premise connections environment and has worked on multiple versions.
However when switching to Connections Cloud, some parts stopped worked.
We get a 403 - Forbidden exception on 2 occasions:
Getting the details of a blog post: /blogs/[blog-id]/feed/entry/atom?entryid=[entry-id]
Getting images inside the blog post: /blogs/[blog-id]/resource/BLOGS_UPLOADED_IMAGES/[image file name]
I have fixed issue 1) by switching to the plublishing API: /blogs/[blog-id]/api/entries/[entry-id].
I cannot find a way to fix issue 2). I have also found 2 other image urls:
https://apps.ce.collabserv.com/blogs/[blog-id]/api/media/[file-name]
https://apps.ce.collabserv.com/blogs/[blog-id]/api/media/BLOGS_UPLOADED_IMAGES/[file-name].media
Both return:
<sp_0:error xmlns="http://incubator.apache.org/abdera" xmlns:sp_0="http://incubator.apache.org/abdera">
<code>404</code>
<message>Not Found</message>
</sp_0:error>
I want to authenticate by using Basic Authentication when possible. This does not appear to work with the given 403 urls.
My guess is that this the basic authentication header is not picked up. I have seen this before.
I used to fix this by first calling another URL that does support basic authentication and using the Ltpa cookies to authenticate the image url.
This also does not work: I do get LtpaTokens, but when I pass all the cookies to the URL, the image still does not work.
I prefer not to use OAuth of OAuth 2 at this moment. Is there any other way to fix this?
Anybody else managed to retrieve BLOGS_UPLOADED_IMAGES?
The issue is can also be reproduced in a browser.
Make sure you are not yet authenticated and the blog has posts with
images
Go to /blogs/[blog-id]/api/media
Authenticate using the popup in the browser The Atom feed now appears. This contains the images of your blog.
403 when opening:
/blogs/[blog-id]/resource/BLOGS_UPLOADED_IMAGES/[image]
404 xml when opening: /blogs/[blog-id]/api/media/* links

Method not allowed when trying to access API methods via SOAP integration

Good day,
I'm having trouble calling DSAPI methods via SOAP ( C# Integration ). I keep getting 405 Method not allowed errors. So far I've tried calling the RequestTemplate and CreateEnvelopeFromTemplates methods, both of which fail. I was able to successfully retrieve the DSAPIServiceSoapClient object and also successfully login via the login method of the credential API. If you need more information, i'm ready to provide them. Thank you.
You're succeeding with the login, which is good.
My guess is that the other calls are not well formed. Perhaps they're missing the right base url (which you receive from the login call).
Are you switching to the different base url for your subsequent calls? (Different server name?)
I suggest that you try the API logging feature and see what it reports. It enables you to see a log of your API requests. See the Request Logging article for the classic DocuSign experience, or the new DocuSign UI.
i just needed to add the in the X-DocuSign-Authentication http header whenever i try to get a DSAPIClient object.

How to prevent 3rd part services from using my API?

I have developed a front-end interface using Aja(AngularJS) and HTML5. Right now, I send an HTTP get request to my backend server which returns some data based on the GET parameters.
Since the URL is exposed in the Javascript file, I believe anyone could just use the URL to create there own API to fetch the data. How can I prevent such things ?
One way I could think of is that now instead of directly sending the request to the backend server, an application server could be used (hosting the HTML as well). The Ajax request would then be sent to this server (PHP script ?) which would in turn forward the request to the backend server and return the result to the UI. To prevent 3rd party services, I can disable cross origin requests on my application server.
Is this the correct way to solve my problem or are there better ways to do this? I am concerned that this would unnecessarily create another hop (internal though) for requests.
Note: The backend is running Apache Tomcat
In APIs that are not open to the world the user has to authenticate first in order to use it, see for example https://stripe.com/docs/api#authentication or http://dev.maxmind.com/geoip/geoip2/web-services/ -> Authorization

Can't debug Netsuite Restlet

I cannot seem to debug a restlet. I keep getting the error:
INVALID_HOST
Invalid host debugger.netsuite.com. Please send RESTlet requests to https://rest.netsuite.com/.
Even though my deployment list the external URL as:
https://debugger.netsuite.com/app/site/hosting/restlet.nl?script=58&deploy=1 and its status is "Testing"
I log into debugger.netsuite.com, click to use an existing script and it provides me with a cookie. I add this cookie to my HTTP request header and am still returned the above error.
The request header I'm sending is:
Cookie: NS_VER=2012.1.0; JSESSIONID=$session_id
Content-Type: application/json
Authorization: NLAuth nlauth_account=$account_id,nlauth_email=$email,nlauth_signature=$password,nlauth_role=
Does anyone know why I can't connect to the debugger?
As mentioned above, having an "Authorization" header along with the Cookie will produce the error you see. Also, make sure of the following:
The RESTlet is deployed in "testing" mode
You are the owner of the RESTlet
Your Netsuite account is enabled for debugging. Not 100% sure on this, but I have two logins, and only one was able to successfully debug a RESTlet.
You may not need this any more but the NetSuite online Help has a page specifically addressing how to debug your RESTlet in the NetSuite Debugger. It describes the process as logging into the Debugger server, then clicking "Debug Existing", then letting your script run. This way, the debugger knows how to help you. Your way, you're trying to run the script through the debugger server but not giving it a chance to grab that script's execution and control it.
Hope this helps.
Look for Advanced Rest Client in the google webstore. The service is free and works very well when debugging Netsuite Restlet.
Your on the right track. You just have to remove your Authorization data as you are already using the Cookie from Debugger to authenticate.
This solution is already available as well in SuiteAnswers

Resources