I decided to write a personal blog engine on Google App Engine.
But I really do not like the idea of adding a login button somewhere. How can I still do admin things, i,e, post an article, delete a comment and etc, without a login button?
One ugly solution may be not showing the login button but still proviing the login url which you can type in manually to login. There is not much difference. I don't like this one.
Any one know some other ways around this? I've seen many blogs without the login button, how do they implement this?
UPDATE:
One offline solution may be using the remote_api provided by App Engine, that is somewhat applicable and I'm considering using it. But you always need the App Engine Toolkit to do it. So it might not be as portable as an online version in which case every thing you need is just a modern and the network connection.
You can restrict access to a specific resource of your application by using the login option in app.yaml handler definition:
- url: /admin
login: admin
script: admin.app
Then using the Users API you can easily check on your main page if the current user in is an admin, and decide to show or not a link to this protected resource:
if users.is_current_user_admin():
# render link to /admin
Related
I have a little bit of problem with the authentication on Sitecore website. Basically there is a button on the navbar, and when user clicks on the button, it redirects the same user to Salesforce to log in (Implementation of SSO). Basically I am using Salesforce as a identity provider and Sitecore Website as a service provider. Now I have a question? When user is logged, how can I get the ID of that user.
Do users in Sitecore User Manager have the same ID as the users in Salesforce, or I can just get a email to identify the user?
P.S: Sorry if this is a really stupid question, but I am a begineer when it comes to making Sitecore websites and the SAML SSO. Thank you in advance
Stop with the Sitecore and Salesforce for a second, you'll need to cover some basics and click through the login process manually before you automate it.
You probably are using a "connected app" in Salesforce that includes OAuth2 config (consumer key also known as client id; a secret; a list of scopes telling what this app is allowed to do on behalf of this SF user; a list of allowed urls that can login using this consumer key and secret. Etc.) It might even have something about Canvas Apps at bottom of the page.
Next would be - who's logging in. A core Salesforce user or do you have Partner Community, Customer Community (recently rebranded to "Digital Experiences").
Open incognito window and go to https://openidconnect.herokuapp.com/
For login host leave as is if you have production user or test.salesforce.com if you go from sandbox (you can also use branded urls, mycompany--dev.my.salesforce.com etc). If you have a community user you'll have to change the url to whatever is the community base url, like https://dev-mycompany.cs123.force.com/mycommunity
Don't change anything else, click next, next, next. This will take you through OAuth2 "web server flow" (one of many ways to log in). You type the username/password to SF screen and go back to that herokuapp with "authorisation code". The app has few minutes to swap that code for actual final "access token" and couple other pieces of info. Final step in this wizard calls OpenId "userinfo" - returning some info about the user that logged in. That's where you could pull the email if needed (and if there are extra fields you'd like SF to return in this process that's configurable too)
Close that browser window. Check the "connected app" in SF. Open new incognito window, do same thing but this time put your url, consumer key and secret (you might have to edit the app in SF first to allow callbacks to https://openidconnect.herokuapp.com/callback).
So now you should have rough idea about whole login process. Your sitecore app probably does same thing, receives authorisation code and exchanges it for final token. At that point you have valid SF session ID you could use to call that "userinfo", run queries (if the app allowes API access, check the "scopes") etc.
I doubt the Sitecore developer created it all by hand, you probably have some Spring stuff like spring.security.oauth2.client... My Java days are long gone but if you get better at manual click-click-click through the flow you should be able to follow existing code?
It's a big topic and there are other ways to do it (other OAuth flows, sending info about the current user when you have external page embedded in SF as iframe, you'd need to read about "canvas apps")... but that's best guess based on info you provided. You might want to check some trailhead courses too like https://trailhead.salesforce.com/content/learn/projects/build-a-connected-app-for-api-integration/implement-the-oauth-20-web-server-authentication-flow
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_oauth_and_connected_apps.htm
https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/code_sample_auth_oauth.htm (Java but very hand-crafted raw HTTP, probably that Spring security is better)
I want to use IdentityServer4 as a common login for my own web applications.
Not all users are free to use all apps and obviously I could make all apps have users be rejected that aren't allowed to access them.
It seems a little more elegant to have a common "this app isn't activated for you" page centralized in the identity server though. That way, I need to implement that page only once. The identity server would have to have knowledge about which user may access which client, but that's reasonable in my scenario: they are all my own apps anyway.
I'm not sure what the right place is to hook the test in. It can't be the login page as the user may already be logged in to the identity server from a client he does have access to.
I wouldn't go for this approach, but I do not know the design of your apps.
I think that the url may confuse the user. Since it is the url of the IdentityServer where they see the "this app isn't activated for you" message. What does that mean to the user and where to go from there?
Besides, IdentityServer is meant to authenticate users, not to authorize users. So it doesn't seem right to move this kind of logic to IdentityServer. It also sounds like extra work.
Keep it simple. Keep authorization close to the resource and create one page with the message. Copy that to all your apps and css does the rest.
And use the default behaviour. In case an anonymous user hits a secured method, the user will automatically be rerouted to the login page. In case an authenticated user hits a method where it doesn't have access, it reroutes to the default (apps) Account/Denied page.
You can override the path in you startup configuration:
.AddCookie("Cookies", options =>
{
options.AccessDeniedPath = "/accountdenied";
})
You can show the "this app isn't activated for you" page, or you can go from there and redirect with code to the IdentityServer page. With the possibility to add additional information to customize the page.
Perhaps you can enter the page of IdentityServer instead, if that fits your design better. I haven't tried it, so I do not know if that's possible.
But in any case I would keep the authorization logic in the app.
I have created a web page with RoR and i am using auth system that i wrote. Now i would like to create an admin panel, where i can see the user info etc..
I am not sure but what i though is to add a column name to auth system like admin? giving a default name false. Then if the admin? is true admin panel opens instead of the web page login.
I wonder if i can use the same auth system so in order to login to page it logs in to admin panel.
But in the controller it will check if admin? is true for every user, i am not sure about the burden in terms of the system requirments as it will check every user.
And i know there are other gems for admin panel but its fine i can design it. I am just not sure which way is the efficient way.
The burden on the system will be negligible. It depends a little bit upon how your auth system is configured, but I am assuming that you give the user a token when he/she is properly logged in.
When the user first tries to sign in, you should check if they are an admin. At this point, if they are, then you can sign them in as an admin, also storing that information in the session. You should perform this check on the controller actions where they need to be an admin. It will not affect performance to any noticeable degree and is important for the security of your site.
Also, you may want to check out the CanCanCan gem, which is a fork of CanCan built by Ryan Bates, for an example of how this works. Unless you're building the application for educational purposes, I highly recommend the CanCanCan gem.
Hope this helps!
In addition to that, you may try Rails_Admin, which provides an easy-to-use interface for managing your data.
And I've considered to use this gem for my project, which is a huge database, so it seems to very helpful.
I'm playing with the oauth2client.appengine Oauth2Decorator and it interjects it's own screen asking for an email address:
The URL is http://127.0.0.1:8080/_ah/login?continue=http%3A//127.0.0.1%3A8080/mypage
I'm guessing that its intention is to mock being different users during development? But that leaves some questions:
Does it only appear on the dev server?
Do I have to do anything to make it go away when deploying to production, or is that magic?
How do I turn it off for development?
What does it actually do?
if the user is being redirected to an oauth consent page nonetheless what's the point of this?
As you can see I just don't get it. I do see that it gives my get_current_user() a result - a user instance with the email address that I submit.
I recognise that this is effectively the same question as
"How to Bypass Local Login Screen with Oauth2 and GAE", which seems to conclude that the whole oauth2client library is fairly useless and it is best that we all go off and write own authentication flows? Seriously?
If that's the state of things alternative suggestions are welcome (in the comments). My workflow is to send the user off to be granted permissions via Google's Oauth so my webapp can proceed to do stuff on their behalf.
If you want to use the get_current_user() that is provided by Google you can't really avoid it and it is actually something very useful. If you want to do your own authentication stuff then just don't use it and you won't be redirected to /_ah/login.
In short this is just to simulate locally the actual Google Login. It would be a huge mess to login to your actual account while on development mode and it will be really hard to simulate multiple users. That code is not executed online and instead you are being redirected to Google for approval.
Is there a way to configure Google App Engine so that the log-in page appears either inline or in an iframe, instead of requiring a link.
I would like it to be as simple as
<iframe src="{{ login_url }}">
<!-- no iframes -->
Log in
</iframe>
However that seems to be an undocumented way to go about logging in users, and I'm not sure if that's the way to go about this.
I'd be grateful for any thoughts
Thank you for reading.
Brian
This is not a good idea. By showing a google login form on your domain how do your users know it is legitimate? By redirecting your users to a page on Google's domain it reduces the amount of confusion.
Also, you might want to review the Terms before doing this. I would not be surprised if Google specifically mentions not doing this somewhere. It's like teaching your users to give up there Google login details whenever prompted.
There have been several posts in the groups discussing this as well; Nick, and many other users, responded to this question with similar comments.
I just tried doing what you suggest here, except that I don't have the hyperlink inside of the iFrame. I want Google's authentication page to appear in the iFrame over my page rather than redirecting to the authentication page and then back to my page. I also append a query string to the login_url, and my main request then returns a simple "Welcome" message rather than my app's main page.
It works beautifully in the sandbox, but it doesn't work when deployed to GAE. The page returned by Google's login_url refuses to be displayed in an iFrame. The console message is "Refused to display document because display forbidden by X-Frame-Options." I've thought about possible workarounds, but Google obviously doesn't want the login page displayed this way. I'm disappointed, because my app uses HttpRequests heavily, so the main page never refreshes otherwise, but I'm still very happy with GAE.