I have to get data as json from a page. But my issue is that you need to be authenticated to the site to be able to see the page. I have an account on the site and I would like to know how to make the authentication or bypass this to be able to make my request, for the moment I have
urllib.error.HTTPError: HTTP Error 403
And here is the code I've made
import urllib.request, json
url = "https://intra.epitech.eu/planning/"
json_url = urllib.request.urlopen(url)
data = json.loads(json_url.read())
print(data)
The epitech intranet gives access to data only if you are logged in with your epitech account (i'm currently a epitech student building an app linked to the intra).
if you are not logged in to the intra you will get a 403 error (the one you have).
to connect to the intra with your account, you either need to use a autologin link (you can generate one in your intra settings) or register a azure active directory app to be able to log in with office365.
Probably you should use API of this website to get protected data. The fact you have an account does not allows you to get data programmatically.
Related
I am using Power Automate for all my API calls to Docusign. I want to be able to capture the authorization code when a user logs into Docusign and then run a flow to get access and refresh tokens.
My flows work when I manually copy the authorization code from a localhost redirection browser session and get the user tokens. I want to be able to redirect to a power automate webhook URL so that when the user logs in, the authorization code is redirected to the power automate webhook trigger where I can grab the authorization code and process it to get user tokens. As an example, I have set up a power automate HTTP webhook trigger and have a URL provided by MS to point to.
https://prod-63.westus.logic.azure.com:443/workflows/887839a887d945919f8a0bb1aa89d2fa/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_3pQLhhEORjAAe3V_IjCPNgBYnHnw2nrdP-oEoIPvyA
I registered this in Docusign as a redirect URL. No configuration or format error was indicated when registering this URL.
When I attempt to log in via a browser session, after entering my credentials, I get a redirection URL not properly registered error.
Are there format or length or other parameters that prohibit the use of this type of URL as a redirection in Docusign?
I'm 90% certain that the URL you are using is dynamic
The sig=_3pQLhhEORjAAe3V_IjCPNgBYnHnw2nrdP-oEoIPvyA
Represent something that will not be the same next time and therefore, my hunch is that it won't do no good to add this type of URL to the list of redirectURI.
You can check to make sure I'm right by looking at the URL you get when you get the error.
If I'm right, then you would have to change your approach to this.
If I'm wrong, then maybe there's some issue with some special character or some other inconsistency and I can ask our engineers to look into this.
It looks to me like you should use the Custom Connector Authorization section of your connector instead of your current approach.
See this doc
I am attempting to retrieve and save an inline image from a Teams message. I have Power Automate reading the message and retrieving the image url. However, with Power Automate I just get 403 errors.
I am setting authentication in the HTTP GET
I can use graph explorer to get the image, so I know the link is correct. I have created an app with permissions in Azure as shown here
Am I missing a permission or something else?
Are you able to perform the same HTTP request on your machine using some tool like Postman?
Sometimes I have timeout issues with Microsoft Flow HTTP requests due to issues with IP whitelisting. Flow uses different IPs you can check it here and you may need to whitelist it first.
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I am trying to use Blueprism to download pdf files from Sharepoint.
I am using the below code. Url and Path are both variables which get passed through. This is producing a 403 forbidden error. I believe that Blueprism is required to pass credentials to Sharepoint before it will be allowed to download the file. Is this possible?
Using wc As New System.Net.WebClient()
wc.DownloadFile(Url, Path)
End Using
I don't think you have a password related issue, likely the SharePoint is recognising your account access via AD group or SSO of some kind. 403 means the server has understood your request but is denying to fulfil it because of an access reason on the profile you have. Make sure you can manually download the file on the profile you are emulating for a start then also check the profile the bot is operating under (not necessarily yours in some cases ) has access to said file.
Literally 403 is a request that relates to an access issue so somewhere something doesn't have the correct access lined up
First of all, is this a Sharepoint Online or OnPremises version? As you understand, you are connecting to web resource via an API and as such you have to get authenticated and authorized to access those resources.
If it's SPO, you can use the API component for SharePoint integration from DX and configure.
In case of SP On prem, you have to customize a lot to achieve your results.
I am trying out the Azure AD-B2C. The user signup/sign in is fine when the MFA is turned off. But when I turn it on, and the user tries to sign in and provides the phone number, and requests a text message by clicking "send code", I get the Http 400 error: size of request headers is too long. Anybody else have this issue?
The error HTTP 400: Size of header request is too long generally happens because there's too many cookies.
Azure AD B2C's login goes through login.microsoftonline.com, as does almost every Microsoft service (O365, Azure, etc). So if you've got several accounts that you've signed in to across these services, you're accumulating cookies that will cause this problem.
Clearing the cookies should resolve this problem. If this is happening on a recurring basis, you should edit your question to include details about the request and cookies in order to best figure out what's bloating the request and how to reduce it.
Short answer: The file with the custom UI was not found by Microsoft login service. After getting shipped around it resulted in the error.
I had the same error with AAD B2C but "cookies" was not the problem. In my case I got the error while testing in the Azure B2C portal checking the policies and the custom UI pages. We use Azure Blob storage to hold custom login setup, its fast and it scales without our attention. The problem was found by using my test website using the B2C service. I put a stop/break on the Account controller's "public Task OnRemoteFailure(RemoteFailureContext context)" method. The debugger message gave me the full context of the error, an http 404 error and it gave the file name it was trying to find. Blob storage is case sensitive. The setup configuration used to configure B2C has camelCase names. The group who created the actual UI customization uses all lower case names. It took someone with access to all the assets to find the simple case name issue. Errors in distributed systems can be difficult.