I have a unapproved chrome extention where I want to add another developer to have access, but I contionously get this Access Blocked error. What is the reason behind this ?
Its driving me crazy and I have googled a lot. 2 things I have tried:
Adding developer to trusted account
Creating Google Groups and giving access of my extention to this group. In this group, I also added the developer who needs access and gets this error.
Sign in with Google
Access blocked: Al-EMAIL-358 has not completed the Google verification process
AI-EMAIL-358 has not completed the Google verification process. The app is currently being tested, and can only be accessed by developer-approved testers. If you think you should have access, contact the developer.
If you are a developer of Al-EMAIL-358, see error details.
Error 403: access_denied
I have added the developer to trusted accounts but it still does not work
Related
I opened a virus file and someone got access to my emails. After this, I have changed the password and enabled 2FA, but the hacker is manipulating my Google Script.
I keep receiving emails, for example:
Your script, Untitled project, has recently failed to finish successfully. A summary of the failure(s) is shown below. To configure the triggers for this script, or change your settings for receiving future failure notifications, click here.
I don't understand what is happening; how can I delete all of these scripts and triggers, and ultimately remove this person's access from my account?
To completely remove all Google apps scripts access from your compromised account,
Change your Google account password
Visit apps script dashboard and remove all triggers and all scripts there.
Visit your Google account third party apps page and remove all apps with permissions there.
Make sure you're logged into the correct google account.
I am currently developping an app which allows Google sign-in. We are asking permissions to get access to the users contacts (for invitation) and agenda (to create events).
Our app has been validated by Google a few weeks ago.
The main issue is that we would prefer to require our users to grant permission to access their accounts during the sign-in process, but we have a (rather long) list of checkboxes that the user must manually click on, which is a really bad UX.
I understand the privacy reason for that behavior, but I know that it is somehow possible, since I've tested that on another app myself (see below)
Google support is non existant on that subject, and the resources I found here or somewhere else are either deprecated or doesn't answer the question.
Have some of you encountered the same problem and fixed it?
Thanks a lot!
These checkboxes are due to the granular account permission change added in 2018. They are there to give the user the option to accept or reject your request, and can not be turned off.
You can read up on this in the original blog post. this Google Developers blog post
In the Azure Portal, in certain scenarios when it prompts me to open a URL in a new tab, I get a 403 error.
"Error 403 - This web app is stopped"
I have followed the help link on that page (https://blogs.msdn.microsoft.com/waws/2016/01/05/azure-web-apps-error-403-this-web-app-is-stopped/), but none of these issues (see footnote for issues) apply to me.
Specific examples of when I get this message:
In an app service > App Service Diagnostics > Collect Memory Dump: the report is available to view in a pop-out URL. When I click on the link, it opens a new browser tab and I can see from the url that it's attempting an oauth sign-in, which eventually displays the 403 page.
In an app service > App Service Editor (Preview), when I click on the "Go" link, as before, it opens a new browser tab and I can see from the url that it's attempting an oauth sign-in, which eventually displays the 403 page.
In both cases, it redirects to a https://****.sso.azurewebsites.net url which displays the 403 message.
Any suggestions?
Footnote: According to that url, there are 3 conditions that can cause this error to be presented.
The site has reached a billing limit and your site has been disabled.
The Website has been stopped in the portal.
The Azure Website has reached a resource quota limit that applies to either Free or Shared scale modes.
Based on Ivan's comment, I checked my role settings. I was a Contributor for this Azure subscription. Since I changed it to an Owner (via Access control IAM > Role Assignments), it now works as expected.
It's frustrating that this is not made obvious in the Azure Portal.
In my case, There were network IP restrictions applied to the site. So I was getting the same error above from my home network. You can check the rules by going to the properties tab. To modify, go to Networking->Configure access restrictions.
If you are only getting the error when you open a new tab, it could be a problem with the maximum number of connections.
Are you running in debug mode? For Basic and below the maximum number of debug connections is 1.
I have a web app in Azure. The access to that web app is controlled by Azure Active Directory. The app is up and running since September of last year. I didn't make any changes to the app for a while and have 33 users in that app.
So, a week ago I tried to add a user, using the same methods and paths I used before.
The new user can log in to microsoft (portal.office.com). After the initial log in and changing of the password the user goes to the web app in Azure and get the following error: You do not have permission to view this directory or page.
Error tracing gives me this:
HTTP Error 401.73 - Unauthorized You do not have permission to view
this directory or page.
Most likely causes: The authenticated user does not have access to a
resource needed to process the request.
Things you can try: Create a tracing rule to track failed requests for
this HTTP status code. For more information about creating a tracing
rule for failed requests, click here.
Detailed Error Information: Module EasyAuthModule_32bit
Notification BeginRequest Handler
ExtensionlessUrlHandler-Integrated-4.0 Error Code 0x80004005
Requested URL https://*******:80/.auth/login/aad/callback Physical
Path D:\home\site\wwwroot.auth\login\aad\callback Logon Method
Not yet determined Logon User Not yet determined
More Information: This is the generic Access Denied error returned by
IIS. Typically, there is a substatus code associated with this error
that describes why the server denied the request. Check the IIS Log
file to determine whether a substatus code is associated with this
failure. View more information ยป
Microsoft Knowledge Base Articles:
Another observed behavior: usually when new users are logging in the web app asks for permissions for the AD to access their account information. Ever since this problem came up this is not the case any more.
Other users do not have any problems logging in. This problem only happens with new users who never logged in before.
EDIT: When I go to Active Directory and look at sign ins, I see failures to log into the web app with sign-in error code 90092. Failure Reason: Other.
Microsoft help desk could not give me details on that error code.
Checkout the related question and answer here. All new users have to first consent the application (agree and give your application permissions to access their profile / or you indicated as required permissions).
In short, you have to design "sign-up" button for your application, which uses the "login_url" and appends "&prompt=consent" to the query string.
Read all related resources here to better understand the consent framework.
And please read the documentation about Azure App Service Authentication/Authorization here, as well as the Azure AD specific documentation here.
OMG, I just found an answer. I created a test app and set it up to mirror the settings of my live app.
In Required Permissions the new app had nothing for Microsoft Graph, the live app had 5 permissions. I deleted Microsoft Graph and it works now!
I wish Microsoft communicated better about discontinued API's. I did get an alert, but it was mostly talking about MS Office 365.
We customised our Azure AD B2C tenant's Combined Sign-Up/Sign-In Policy to serve up our own login page. This worked across all the major browsers when we tested last week, but it stopped working today for some of our users on Chrome and Firefox.
We are getting this 404 error when some of our users browse to our home page and they get redirected to the login page (our B2C tenant and custom login URL is redacted but all other query parameters are unchanged):
https://login.microsoftonline.com/redacted.onmicrosoft.com/B2C_1_sign_up_in/api/CombinedSigninAndSignup/error?code=UX004&diags=%7B%22version%22%3A%222.0.0%22%2C%22user-agent%22%3A%22Mozilla%2F5.0%20(Windows%20NT%2010.0%3B%20Win64%3B%20x64%3B%20rv%3A54.0)%20Gecko%2F20100101%20Firefox%2F54.0%22%2C%22online%22%3Atrue%2C%22trace%22%3A%5B%22%231%20T005%20(3ms)%22%2C%22%232%20T027%22%2C%22%233%20T021%20(37ms)%22%5D%2C%22code%22%3A%22UX004%22%7D&csrf_token=YzQ0N3F3NXlTVzBVWTFraG96cmlVU3FVbjVNRmZRbHZ6RURIaHdPRExNRTlDRVRNL3hPN00xRXhoOUV0bnE0V3pYc3ZYcEg0YzRhVnp5WE5QYTJZN0E9PTsyMDE3LTA4LTA4VDAwOjU3OjM2Ljc3MjM1MDlaO283Mm9nSFVXb3lIbWtVZy9CeHZVbFE9PTt7Ik9yY2hlc3RyYXRpb25TdGVwIjoxfQ==&tx=eyJUSUQiOiI4MDgwNWE3Ny02OTU2LTRiNGMtYmUyYi05OGZkZGEwYzM4MDkifQ&desc=https%3A%2F%2Fourdomain.redacted.html
We have tested the following with no success:
Clearing all our cache and cooking
Disabled all extensions
Private browsing/Incognito mode
Chrome on Android
But Internet Explorer loads the custom sign-in page just fine on their computer!
I have tried searching online for error code UX004 but didn't find anything. Can someone from Microsoft advise what this error code means? Thank you.
I didn't get any response from Microsoft, but we tried various fixes. The one that worked for us is to apply a SSL certificate issued by a commonly-trusted issuer on our test domain. I can't confirm that this error message means AAD B2C is complaining of an insecure connection, but it's worth exploring in case it works for anyone else too.
It appears as though this may be a CORS issue on your hosted login page. Use (F12) to open up your developer tools, look into the Console tab and ensure you have Preserve log switched on. Navigate to the website and hopefully the error should be visible.
For me it was a CORS issue with the storage account. Adding a CORS rule that allowed everything solved the problem.
Go to azure portal (https://portal.azure.com) and open the storage account that contains your custom login page templates. In the right hand navigation find Settings > Resource sharing (CORS)
Add a new rule with the following values
Allowed origins = *
Allowed methods = Select all items
Allowed headers = *
Exposed headers = *
Max age = 200
Hopefully that helps!