shinyproxy: how to bypass login page feature to avoid logging twice? - shinyproxy

I already have a login page in my organization which access users' ID and password from HR system (see below).
My question is: how can I bypass the built-in login feature of shinyproxy and the navbar above my app(see picture below)?
Thanks for any suggestion and comment.

I find the solution as follows:
Just set authentication: none and hide-navbar: true in proxy in application.yml, and that's it.
proxy:
title: Standalone Docker Engine with euler Example
port: 8080
authentication: none
hide-navbar: true

Related

Redirect URL changes from https to http after users authenticated with azure active directory in azure aks

I've been struggling to find a solution for this issue. Basically I have web application that allows users to sign in with their azure active directory using OpenIdConnect. Everything works perfectly fine on my local. However, when deployed to azure aks, somehow the redirect url changes from https to http when user is authenticated. This causes an exception in azure ad:
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
I defined the redirect URI in the application as https://example.abc.com/signin-oidc and no wonder that it does not match. However, I'm struggling to find out why it's happening and how I can resolve it. I'm using .NET 6 and AKS client version 1.22.
Any help would be greatly appreciated. Thank you
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
The above error occurs usually when redirect Url in the authentication are not configured in Azure AD like.
Accessing Website from a different address than what you have defined for your application causes an error.
please check if you have made a mistake in the configuration itself.
From your case :
Please make sure you set ssl redirects url to True
Note:
By default controller redirects HTTP clients to 443 port -https ,if it has TLS is enabled
In ingress routing yaml file if it is set to false, try to set it or modify it to true
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Also as you said you are using .net make sure you have set headers to true.
Please check that header size in 32k in annotations.
nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
Reference:
Error AADSTS50011 - The reply URL specified in the request does not match the reply URLs configured for the application . - Active Directory | Microsoft Docs
I finally figured out the solution for myself. Thanks to the answer in other SOF
Since I'm using .NET 6, all I have to do is
Set the ASPNETCORE_FORWARDEDHEADERS_ENABLED = true AND
Add these two lines suggested from #Venkatesan to my ingress yml
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Everything works perfectly after that.
Thank you everyone.

Safaricom dashboard does not show all the test credentials

I am working on Safaricom Daraja API B2C but some of the required test credentials are not displayed in the Safaricom Dashboard.
As you can see above, the initiator name and security credentials are not provided yet they are needed in the B2C API call.
How do I get these credentials.
EDIT:
This question was asked before Safaricom upgraded to the new Daraja Dashboard. The problem has now been sorted
Apparently, for some unknown reason to us, Safaricom chose to hide the test credentials and if you need them, you have to write them an email at apisupport#safaricom.co.ke and request for the test credentials. You will get a response in less than an hour with shortcodes and initiators that you can use for test.
Source -> https://survtechnologies.co.ke/get-test-credentials-safaricom-m-pesa-daraja-api/
The test Credentials are on the simulator link, bottom right redirects to the link.
Please try this with the new mpesa portal2.0 - It is straight-forward

Porting app from react-azure-adb2c to react-aad

I am using Azure AD B2C. I need some react library to authenticate users in my react.js app.
I started with react-azure-adb2c. Primary scenarios like login and logout worked well for me. However, the library owner stopped supporting the library, so I need to find other one.
Experimenting with react-aad.
I used the example and got nice page that suggests popup or redirect login. However, both do not work. Most likely my configuration contains errors.
If I do not provide authority, I get microsoft auth page, not for my tenant. If I provide 'https://x5aaas.b2clogin.com/x5aaas.onmicrosoft.com', as directed by this post, i see error in console "endpoints_resolution_error:Endpoints cannot be resolved".
It seems there are some configuration mistakes:
provider={
new MsalAuthProviderFactory({
authority: 'https://x5aaas.b2clogin.com/x5aaas.onmicrosoft.com',
clientID: 'a1568977-3095-4bf6-a6d6-c10c87658488',
scopes: ['https://x5aaas.onmicrosoft.com/ui/use'],
type: LoginType.Redirect,
persistLoginPastSession: true,
postLogoutRedirectUri: window.origin.location,
})
}
I use basic react app with type script, created with
npx create-react-app <appName> --typescript
What can be wrong here?
The value of the authority is not correct. You should use https://login.microsoftonline.com/tfp/<your-tenant-name>.onmicrosoft.com/<your-sign-in-sign-up-policy>
The value of your-sign-in-sign-up-policy is the name of the policy.

Program access admin on GAE - oauth2

I have a GAE app, with a URL I restrict to admin:
- url: /admin
script: _go_app
login: admin
I want to PUT or POST to this url with another Go program. What code do I need to write for the client to authenticate to GAE and dev_server.py? Is there a more sensible way that just mocking a web-browser and logging in? I don't need to authenticate or authorise other users, just the admin account for that app.
Is this OAuth? OAuth2? OpenID? Federated? Something else?
I realise this is a bit of an awkward question, since I'm not even sure what the right way to ask it is. However I am able to post to (in this example) /admin using a web browser after logging in with my (admin) gmail account. In that case the request (sent by Chrome) contains the cookies: __cfduid, ACSID (and what I think are Google Analytics IDs). Presumably one of those is responsible for my authentication. How do I get one of those?
And as a side question, if someone MITMs my connection (over http), can they hijack my admin session by reusing that cookie?
GAE likes OAuth2
Have a look at goauth2 . It seems to be the canonical OAuth2 library for Go. They provide a fairly comprehensive example at https://code.google.com/p/goauth2/source/browse/oauth/example/oauthreq.go .
With regards to your question "Presumably one of those is responsible for my authentication. How do I get one of those?", they state:
To obtain Client ID and Secret, see the "OAuth 2 Credentials" section under
the "API Access" tab on this page: https://code.google.com/apis/console/
And, finally, my humble opinion on "if someone MITMs my connection (over http), can they hijack my admin session by reusing that cookie?" is that you should never provide any authenticated connection (nor the connection that does the authentication) over plain http. Especially an admin section.
EDIT: To elaborate on the MITM question, make sure you use HTTPS for any login requests and subsequent requests for the same session, and make sure to set Secure and HttpOnly flags on your cookies.
OAuth2 if you want to use Google Accounts.
See here for details: https://developers.google.com/appengine/docs/go/users/overview (this section specifically deals with admin views)

App Engine remote_api with OpenID

I've recently tried to switch my app engine app to using openID, but I'm having an issue authenticating with remote_api. The old authentication mechanism for remote_api doesn't seem to work (which makes sense) - I'm getting a 'urllib2.HTTPError: HTTP Error 302: Found', which I assume is appengine redirecting me to the openid login page I've set up.
I guess I'm missing something fairly obvious. Currently my remote_api script has the following in it -
remote_api_stub.ConfigureRemoteDatastore(app_id=app_id, path='/remote_api', auth_func=auth_func, servername=host, secure=secure)
where auth_func is
def auth_func():
return raw_input('Username:'), getpass.getpass('Password:')
Any ideas what I need to supply to remote_api? I guess similar issues would be encountered with bulkloader too. Cheers,
Colin
This was a fun one.
Looking at remote_api, the flow for authentication seems to be something like this:
Prompt the user for Google credentials
Post the credentials to https://www.google.com/accounts/ClientLogin
Parse the auth token out of the response body
Pass the token to https://myapp.appspot.com/_ah/login
Grab ACSID cookie set in the response
Pass the ACSID cookie in subsequent requests that require authorization
I couldn't find a lot of documentation on the new OpenID support, though Nick's blog entry was informative.
Here's the test app I wrote to see how things work:
app.yaml:
handlers:
- url: /remote_api
script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
login: admin
- url: /.*
script: test.py
test.py:
class MainPage(webapp.RequestHandler):
def get(self):
user = users.get_current_user()
if user:
self.response.out.write("Hi, %s!<hr>admin is %s" % (user.user_id(),
users.is_current_user_admin()))
else:
self.redirect(users.create_login_url('/', None,
'https://www.google.com/accounts/o8/id'))
Flipping my auth mode between Google Accounts and Federated Login, I noticed a few things:
Admin users are correctly recognized by is_current_user_admin() with OpenID
Mixing modes doesn't work. With authentication set to Google Accounts, calling create_login_url with a federated_identity throws a NotAllowedError
An ACSID cookie is still produced at the end of the login process, only it comes from /_ah/openid_verify instead of /_ah/login
So what's happening with remote_api when using Federated Login? If we're using the default appengine_rpc.HttpRpcServer, it's dutifully following the same Google Account authentication process described at the top, only the app no longer considers the ACSID cookie returned by /_ah/login to be valid, so since you're still unauthenticated, you get a 302 redirect to the OpenID login page, /_ah/login_required.
I dunno what the right solution is here. Seems like it would require an API update. Maybe Nick or one of the other Googlers can weigh in.
For now, here's a hacky workaround:
Turn on Federated Login for your app
Make sure you're passing save_cookies=True when calling remote_api_stub.ConfigureRemoteDatastore for your console script
Attempt console authentication and get the 302 error
Login as an admin via your app's web interface
In your browser cookies, find the ACSID cookie for myapp.appspot.com
Find and edit your local ~/.appcfg_cookies file
Replace the ACSID cookie for myapp.appspot.com with the one from your browser
The next time you try to use remote_api, it should work without prompting for credentials. You'll have to repeat the last 4 steps every time the cookie expires, though. You can bump the expiration from 1 day to as high as 2 weeks in the admin console to minimize the annoyance. Have fun!
This is definitely an issue... mark your interest in getting Google to fix this by starring the ticket at http://code.google.com/p/googleappengine/issues/detail?id=3258 and feel free to add any of your workarounds there.
On a related note, we also recognize that the docs are somewhat sparse, so I'm working on an article which hopefully fills-in some of those holes... stay tuned and keep your eyes open at http://code.google.com/appengine/articles
Here's a workaround you can use until there's a more permanent solution in place.

Resources