kaethorn / alfred

Manage & read your comics
https://alfred.cx
33 stars 1 forks source link

Is there any way to run this without the gmail login... #91

Closed geezer500 closed 2 years ago

geezer500 commented 3 years ago

I'm struggling to get the google sign-in to work.

After having setup a gmail account for the user login, and setting up some form of app in order to get a client ID, I still don't know where to find the auth.jwt.secret. My users (family) don't have gmail accounts (IOS users) and are unlikely to get one just to access this app. I might use it for myself if I could work out what is needed to get it going.

The alfred and mongo containers run fine and appear to be linked. I just can't login.. (nothing happens when I click on the login button) and nothing is recorded in the logs)

Is there any way to just have a login and password to access the app? (or maybe a quick runthru of what I need to do to get the required credentials)

Thanks

kaethorn commented 3 years ago

Hi @geezer500,

seems you're almost there.

The JWT secret is optional. You can generate one (e.g. using pwgen) or specify a custom secret string. The purpose of the secret is to protect your application against people who found out your Client ID. The important part is that you use the same secret (or none) whenever you start alfred, especially once you sign in, since the JWT each user receives is based on it.

Did you specify your user in auth.users? It should be a comma separated list of Google IDs (usually your Google email address).

If all that fails, please get back to me, preferably with some debugging output from your browser (e.g. Chrome Dev Tools) so I can figure out where exactly the login fails.

Username & password login is not something I have planned right now, but it could be implemented without too much trouble. Google Sign-In (or similar OAuth services) are really simple to use - especially on mobile devices. But I understand your pain for users that don't have such an account. I'll keep it in mind.

geezer500 commented 3 years ago

Hi kaethorn :-)

Many thanks for your reply. This is more of an error due to my lack of knowledge I'm afraid... I'm not exactly a noob, however the google API is new to me.

Weirdly today I'm getting google pop-up errors (yesterday I had nothing at all..). I did however delete the container and rebuild it.

I've left out the JWT part for the time being.

No matter what I put into the "Authorised JavaScript origins" & "Authorised redirect URIs" fields I get the same errors (it never changes)

I'm running the docker container on my server from home and use a Dynamic DNS service (duckdns) with a reverse proxy. I can reach the Alfred container both locally and from the net.

The error I get locally is Authorisation Error Error 400: invalid_request Permission denied to generate login hint for target domain.

and the remote error is Authorisation Error Error 400: redirect_uri_mismatch The JavaScript origin in the request, http://xxx.xxxxxx.duckdns.org, does not match the ones authorized for the OAuth client (this remains the same even if I put the exact address (http://xxx.xxxxxx.duckdns.org) in the origins or redirects fields.

I think I'm missing something obvious here :-( (can it work using a DDNS?) Would you mind explaining what exactly I should put in those fields even if to just get it working locally.

Thanks again for your time :-)

kaethorn commented 3 years ago

Your setup isn't much different from mine. I also use a reverse proxy (haproxy) and a DDNS via cloudflare. I believe your duckdns.org address needs to be in the Authorised JavaScript origins field. The redirect URLs can be localhost. Here's how it looks for me:

Screenshot from 2021-03-29 16-49-36

I get the same error than you have if I use the HTTP address instead of HTTPS. Perhaps both your host and Google-OAuth-Settings need to use the same protocol?

geezer500 commented 3 years ago

Hi kaethorn,

Once again thank you for your time... :-)

I had already tried my duckdns address in the Authorised JavaScript origin field, as well both HTPP and HTTPS.

However just to be sure I deleted both the mongo & Alfred containers and followed your commands again to recreate and run them.

I put the duckdns in the Authorised JavaScript origin field again... and used localhost for the redirect URL. Unfortunately it still didn't work.

Just to be sure I opened a totally separate port in my router and ran Alfred on it, then I disabled my reverse proxy and checked that I could access Alfred with just my base duckdns address and the new port (it was reachable). I put that address in the Authorised JavaScript origin field which still didn't work.

I'm at a loss. I think it should work... however i did notice a couple of strange things.

1) I got exactly the same errors whether the mongo container was running or not. 2) I signed in from another browser that I never used (chrome) and I was not logged into gmail, when I clicked on the sign-in button it threw up exactly the same error... not being signed in should it not ask me for my gmail credentials? I wasn't logged in that browser so where was it getting the credentials from? 3) After pressing the sign-in button a pop-up would appear with the error... in the address bar of the pop-up was this https://accounts.google.com/signin/oauth/error?authError=----client_id=4014xxxxxx.apps.googleusercontent.com (I've shortened it and hidden the credentials apart from the 1st 4 digits). client_id=4014xxxx are NOT my credentials... mine start with client_id=2942xxxxx.

Is it possible that somehow I'm not sending the right credentials in the first place which why the address can't authorise?

Thanks :-)

kaethorn commented 3 years ago

Hey @geezer500,

seems like there is an old ClientID still present in the source code in main/resources/application-prod.yml starting with 4014. I've removed those now, so if you pull master again, it might work. I believe any values in the YAML file will override those you pass to the container.

geezer500 commented 3 years ago

Hi kaethorn.

I'm afraid I'm still struggling... I'm still getting the same error

I deleted both the containers and images for mongo and Alfred and repulled;

docker pull kaethorn/alfred:latest

Just to make sure that I'm doing things correctly I'm going to paste the commands I'm using

docker network create alfred-net

docker run -d -p 27017:27017 --name mongo mongo:3.6

docker network connect alfred-net mongo

docker pull kaethorn/alfred:latest

docker run --dns 8.8.8.8 -p 5000:8080 --net=alfred-net --rm \ -v /MyPath/alfred/Comics:/comics \ -v /MyPath/alfred/logs:/logs \ -e SPRING_PROFILES_ACTIVE=prod \ -e SPRING_DATA_MONGODB_URI=mongodb://mongo/alfred \ -e COMICS_COMICVINE_APIKEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -e LOGGING_FILE=/logs/alfred.log \ -e AUTH_CLIENT_ID=2942xxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com \ -e AUTH_USERS=fxxxxxxxxxxxxxx@gmail.com \ -name alfred \ kaethorn/alfred:latest

I've completely left out the JWT line as I'm unsure exactly how to generate one and you mentioned that it was optional.

This is what I've added to google credentials Capture

The duckdns address is reachable on my reverse proxy and has a Let's Encrypt SSL. I've tried both HTTP & HTTPS in the origins field (I'm a little unsure what to put in the redirect field)

kaethorn commented 3 years ago

Thanks for your patience!

I'm also using HTTPS via Let's Encrypt SSL, so that should work nicely.

I'm also not sure about the redirect fields and am honestly surprised that it works on my end using localhost. Can you please try adding http://localhost:8080/login to the list of redirect URIs?

How about we reduce the complexity a little to see if your Google Sign-In setup is picked up correctly? Could you please try adding http://localhost:5000 to the list of Authorised JavaScript origins, start the container and see if you can log in locally via http://localhost:5000?

geezer500 commented 3 years ago

Hi kaethorn,

No worries about patience.. thanks for yours!

When I try to access Alfred locally the error I get is different. It's Error 400: invalid_request Permission denied to generate login hint for targetdomain.`

Capture

So I tried the suggestions you made and they didn't work. However I believe that this is because I run my docker containers on a headless ubuntu server in the basement. So I'm not actually localhost. Also I can't put the IP (of my server) directly into the Authorised JavaScript origins it won't accept it.

I managed to get around this issue by using xip.io - So I put http://192.168.1.12.xip.io:5000 into Authorised JavaScript origins and accessed it by using that address in my browser (it resolves to http://192.168.1.12:5000).

The error now changes from the one above to same one as before, when I was using the duckdns address. Authorisation Error Error 400: redirect_uri_mismatch. The JavaScript origin in the request, http://192.168.1.12.xip.io:5000, does not match the ones authorized for the OAuth client

Note that I get this 2nd error regardless of whether http://192.168.1.12.xip.io:5000 is in my Authorised JavaScript origins.

So It appears my Google Sign is just not working. I tried accessing Alfred from another machine just to make sure that there were no issues with mine, unfortunately I met with the same errors.

From my portainer logs whilst Alfred is running I and tried to access it

at java.base/java.lang.Thread.run(Unknown Source) 2021-03-31 20:32:02.532 ERROR 1 --- [nio-8080-exec-3] de.wasenweg.alfred.security.JwtService : Exception while verifying token. com.auth0.jwt.exceptions.JWTDecodeException: The token was expected to have 3 parts, but got 1. at com.auth0.jwt.TokenUtils.splitToken(TokenUtils.java:21) at com.auth0.jwt.JWTDecoder.<init>(JWTDecoder.java:34) at com.auth0.jwt.JWTVerifier.verify(JWTVerifier.java:260) at de.wasenweg.alfred.security.JwtService.verifyToken(JwtService.java:33) at de.wasenweg.alfred.user.UserService.verify(UserService.java:38) at de.wasenweg.alfred.user.UserController.verify(UserController.java:25) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190) at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Unknown Source)

I believe that issues is the fact that I'm not actually signing in with the right client ID. It's always got client_id=4014x in the address bar when it fails.

Capture

kaethorn commented 3 years ago

However I believe that this is because I run my docker containers on a headless ubuntu server in the basement. So I'm not actually localhost.

I've got the same setup, running alfred on a Synology NAS in my basement. Still, I cannot explain why the localhost redirect URIs work for me.

Since your container is still picking up the wrong Client ID, I believe that it's still stored in the DB since you pulled the latest alfred image. Could you please delete your Mongo DB image and create a new one?

fcimeson commented 3 years ago

PS. Is this going to change in the future? Only being able to login via google is a higher bar than a preset username/password.

fcimeson commented 3 years ago

I don't think I have time to play with the google API, so unfortunately I won't be able to try this app.

+1 to this feature (login without google).

kaethorn commented 3 years ago

@fcimeson I fully understand and will keep this in mind for a future update. The reason I chose to implement Google OAuth from the start is because I didn't want to frustrate my users with yet another username/password while they already have a Google account.

nakedlitttlezombie commented 3 years ago

found the issue line 42 in ui/src/app/user.service.ts just changed that client id and rebuilt the image

kaethorn commented 3 years ago

@NakedLittleZombie good catch! I'll fix this today, if possible.

kaethorn commented 3 years ago

Feel free to reopen this issue if you believe it's still not fixed.

kaethorn commented 3 years ago

The last fix was not sufficient, I'm investigating a solution.

kaethorn commented 2 years ago

This is implemented and should be working now. Please feel free to reopen if you encounter any issues.