gmail oauth2与Intranet Web服务器访问
有人知道云项目的正确设置和以下情况的应用程序中重定向URL吗?
设置:
- spring + apache
- the应用程序已安装在服务器上(Windows ,Linux*),并通过浏览器在Intranet上访问。
*)在有或没有桌面
下
- 的
- 情况 关于服务器的
- 创建访问的创建是由管理员在浏览器
- 同意帐户中仅完成一次的客户端的客户端的,仅在创建时完成一次,在背景线程中检索电子邮件(没有用户互动,即将自动刷新代币)
- 没有其他设置 )在客户端上(例如,更改主机文件,运行背景程序/侦听器);客户端也可以是访问Intranet
范围的移动设备:
- 非限制性:userInfo.Email
- 限制:gmail.modify
云项目设置/尝试:
云项目:桌面应用;应用程序:- 不起作用 - 如果使用此操作,则在服务器上打开同意屏幕授权codeinstalledapp.authorize
云项目:desktop -app;应用程序:上的重定向URL和弹出式 - 工作 - 但是Google IS 停止OOBurn:ietf:wg:oauth:2.0:oob
作为client当前>:云项目:带公共重定向URL的Web应用程序;应用程序:重定向到我们的网站 - 仅显示auth代码,这些代码可以粘贴在浏览器中的应用程序
中的应用程序中public String getAuthorizationurl(字符串客户端,字符串clientEcret,字符串recertentialPath) { 最终的nethttptransport http_transport = googlenethttptransport.newtrustedtransport(); 最终JSONFACTORY JSON_FACTORY = gsonFactory.getDefaultInstance(); 最终列表< string>范围= arrays.aslist(new String [] {gmailscopes.gmail_modify,oauth2scopes.userinfo_email}); 详细信息=新详细信息(); lidess.setClientID(clientId); lidess.setClientsecret(clientsecret); googleClecteCrets clientsecrets = new GoogleClecteCrets(); clientsecrets.setInstalled(详细信息); //构建流量并触发用户授权请求。 googleauthorization codeflow flow = new googleauthorizationCodeflow.builder(Builder( http_transport,json_factory,clientsecrets,示波器) .setDatastoreFactory(新的filedatastoreFactory(新文件(recredentialPath))) .setApprovalPrompt(“力”) .setAccessType(“离线”) 。建造(); /*桌面应用不需要批准提示和访问类型; *无论如何都会生成刷新令牌,必须添加它们以进行Web应用 *要获得刷新令牌 */ 字符串rediruri =“ https://example.com/redirect”; 授权coderequesturl授权= flow.newauthorizationurl()。setRedirecturi(rediruri); 返回授权ur.build(); }
Google Oauth验证中的应用程序打开的应用程序中: Google说,根据生成的流量,该应用程序正在Web服务器上运行,我们需要将其更改为本地URL,否则我们需要进行安全评估,因为数据存储在Web服务器上。 从技术上讲,它在Web服务器上运行是事实,但它是Intranet服务器。 由于服务器在其服务器上安装应用程序的每个用户可能会有所不同,因此无法定义固定的本地URL。
Does anyone know the correct setup for the cloud project and redirect URL within the application for the following case?
Setup:
- Spring + Apache Wicket
- The application is installed on a server (Windows, Linux*) and accessed on the intranet via browser.
*) with or without desktop
Requirements:
- Access to one or more Gmail-Accounts to retrieve emails, mark emails as read and move emails to trash
- Credentials are stored for each account separately on the server
- Creation of the access is done on a client by an admin user in the browser
- Consent for an account is done only once on creation, emails are retrieved in a background thread (no user interaction, token is refreshed automatically)
- No additional setups on the clients (e.g. changing the host-file, running a background-process/listener); Client could also be a mobile device accessing the intranet
Scopes:
- Non-Restricted: userinfo.email
- Restricted: gmail.modify
Cloud projects setups/attempts:
Cloud project: Desktop-App; Application:- Does not work - the consent screen is opened on the server if this is usedAuthorizationCodeInstalledApp.authorize
Cloud project: Desktop-App; Application:- Worked but Google is discontinuing ooburn:ietf:wg:oauth:2.0:oob
as redirect url and popup on the clientCurrent: Cloud project: Web-App with a public redirect url; Application: redirected to our website - only to show the auth code, which can be pasted in the application open in the browser
public String getAuthorizationUrl(String clientId, String clientSecret, String credentialPath) { final NetHttpTransport HTTP_TRANSPORT = GoogleNetHttpTransport.newTrustedTransport(); final JsonFactory JSON_FACTORY = GsonFactory.getDefaultInstance(); final List<String> SCOPES = Arrays.asList(new String[] {GmailScopes.GMAIL_MODIFY, Oauth2Scopes.USERINFO_EMAIL}); Details details = new Details(); details.setClientId(clientId); details.setClientSecret(clientSecret); GoogleClientSecrets clientSecrets = new GoogleClientSecrets(); clientSecrets.setInstalled(details); // Build flow and trigger user authorization request. GoogleAuthorizationCodeFlow flow = new GoogleAuthorizationCodeFlow.Builder( HTTP_TRANSPORT, JSON_FACTORY, clientSecrets, SCOPES) .setDataStoreFactory(new FileDataStoreFactory(new File(credentialPath))) .setApprovalPrompt("force") .setAccessType("offline") .build(); /* approval prompt and access type were not needed for desktop-app; * refresh token was generated anyway, they had to be added for web-app * to get a refresh token */ String redirUri = "https://example.com/redirect"; AuthorizationCodeRequestUrl authorizationUrl = flow.newAuthorizationUrl().setRedirectUri(redirUri); return authorizationUrl.build(); }
Google Oauth verification:
Google says that according to the generated traffic, the app is running on a web server and we need to change it to a local URL, otherwise we need a security assessment because the data is stored on a web server.
While it's technically true that it's running on a web server, it's an intranet server.
It's not possible to define a fixed local URL since the servers IP could be different for each user that is installing the app on his server.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您在这里有几个问题。首先是您使用桌面应用程序来运行Web应用程序。 googleauthorizationCodeflow.builder旨在与已安装的应用桌面应用程序或控制台应用程序一起使用。它的设计不是为托管在Web服务器上的运行。
请按照以下示例 Web服务器应用程序
安装应用程序。
你已经说了这个
这对我来说意味着您正在将该应用程序的代码直接提供给您的用户。这包括您的dredeitnals.json文件。您可能不这样做是针对TOS的。 客户ID?
您应该指示用户如何创建自己的客户端ID和客户端分泌。为了获取自己的信用n.json文件。
然后,他们可以提供自己的服务器的IP地址。
在这种情况下,您的验证问题不再是问题。您不需要为他们求爱。他们应该自己做。
当您的用户验证他们的应用程序时,请重新推开应用程序
,请确保与Google清楚地知道这是一个内部应用程序。托管在他们的Intranet上。他们不需要验证。
You have several issues here. The first is that you are using a desktop application to run a web app. GoogleAuthorizationCodeFlow.Builder is designed for use with installed apps desktop apps or console applications. Its not designed to be run hosted on a web server.
Follow the following example Web server applications
installing app.
You have stated this
Which implies to me that you are giving the code for this app directly to your users with out it being compiled. This includes your credeitnals.json file. YOu may not do this this is against the TOS. Can I really not ship open source with Client ID?
You should be instructing your users in how to create their own client id and client secrete. in order to get their own creditnals.json file.
They can then supply their own ip address of their server.
In which case your issue with verification is no longer an issue. You dont need to verfy for them. They should be doing that themselves.
push back on internal app
When your users go to verification their app make sure that they are clear with Google that this is an internal app. Hosted on their intranet. They should not need verification.