Blank site when i login into the Webinterface #328
Comments
|
Hm, that's weird. Do you use the Docker image or the binaries from the release page? Also, could you please repeat the login process with the developer tools of the browser open?
|
|
Hi, |
|
This is actually really odd, because this handler should never return a blank I tried to reproduce this by downloading the binaries (release 1.27.0) and running them on a completely clean MariaDB as well as Redis instance and was not able to reproduce this behavior. Either there is an issue with your configuration or with your routing / rev proxy environment. For my testing, I've used the following config: configVersionPleaseDoNotChange: 6
codeexec:
ranna:
apiversion: v1
endpoint: 'https://public.ranna.zekro.de'
token: ''
type: ranna
database:
mysql:
database: 'shinpuru'
host: 'localhost:3306'
password: 'dev'
user: 'root'
type: mysql
cache:
redis:
addr: "localhost:6379"
type: 0
cachedatabase: true
discord:
clientid: '911603978758914089'
clientsecret: '***'
generalprefix: ;;
ownerid: '221905671296253953'
token: '***'
disabledcommands:
logging:
commandlogging: true
loglevel: 5
permissions:
defaultadminrules:
- +sp.guild.*
- +sp.etc.*
- +sp.chat.*
defaultuserrules:
- +sp.etc.*
- +sp.chat.*
schedules:
storage:
minio:
accesskey: 'dev-access-key'
accesssecret: 'dev-secret-key'
endpoint: 'localhost:9000'
location: us-east-1
secure: false
type: minio
twitchapp:
clientid: "***"
clientsecret: "***"
webserver:
addr: :8080
apitokenkey: "***"
enabled: true
landingpage:
showlocalinvite: true
showpublicinvites: true
publicaddr: http://localhost:8080
captcha:
sitekey: "20000000-ffff-ffff-ffff-000000000002"
secretkey: "0x0000000000000000000000000000000000000000"
metrics:
enable: true
addr: ":9091"Could you please provide your config (with the secrets removed ofc) just so that I can have a look over it? |
|
This is my config! configVersionPleaseDoNotChange: 6
discord:
token: "xxx"
generalprefix: ";;"
ownerid: "312998964465238018"
clientid: "925204349028819026"
clientsecret: "xxx"
globalcommandratelimit:
burst: 1
limitseconds: 10
permissions:
defaultuserrules:
- +sp.etc.*
- +sp.chat.*
defaultadminrules:
- +sp.guild.*
- +sp.etc.*
- +sp.chat.*
database:
type: "mysql"
mysql:
host: "localhost"
user: "database_user"
password: "database_password"
database: "database"
cache:
redis:
addr: "localhost:6379"
password: "redis_password"
type: 0
cachedatabase: true
logging:
commandlogging: true
loglevel: 4
storage:
type: "file"
minio:
endpoint: "minio.exmaple.com"
accesskey: "my_minio_access_key"
accesssecret: "my_minio_access_secret"
location: "us-east-1"
secure: false
file:
location: /home/dcbot/data
webserver:
enabled: true
addr: 0.0.0.0:80
tls:
enabled: false
cert: "/etc/cert/mycert.pem"
key: "/etc/cert/mykey.pem"
publicaddr: "http://api.theuwuclan.de"
debugpublicaddr: "http://localhost:8081"
ratelimit:
enabled: true
burst: 50
limitseconds: 3
twitchapp:
clientid: "f34eqnjavd5so30yoivbu9ls5pjfek"
clientsecret: "xxx"
metrics:
enable: true
addr: ":9091"
schedules:
guildbackups: '0 0 6,18 * * *'
refreshtokencleanup: '0 0 5 * * *' |
|
I've tried around to find differences in your config to mine and just found you are setting Do you have any kind of reverse proxy between shinpuru and the entrypoint? Have you tried it with your config on a local system hosting via localhost? If yes, does this result in the same issue? |
I had tried out now with your config and now i became this in the logs:INFO[2022/01/15 07:01:14 CET] Starting up... i dont know if this helps but i thinked i just should send this to you. |
|
That's interesting, at least it means that the request comes in to shinpuru and is getting handled in some way. I've added a lot of debug log output to the handlers in question which might give some crucial information to see what is actually going on in there. Could you please download the binary from this build and run a full OAuth2 login procedure. Then, please provide the logs generated. The log output should look similar to that: The essential log outputs in question are all prefixed with |
|
|
Okay, this is actually really interesting. That means, the auth code passed via the callback is not valid for whatever reason. First of all, I discovered that the error handler of the OAuth module did not forward errors correctly. That's why an invalid authentication returns a This will still not fix your problem, because, for some reason, the obtained auth token is not valid in your login flow. Could you please check if you are using the right credentials for your Discord App (client ID, client secret). You can now use the canary build, if you want. It should at least return the right error responses now. ^^ |
|
Before i wanted to setup the canary, i had reconfigured the config now and resetted the database in mysql but im being redirecting to the main page but not getting logged in. |
Edit: |
|
Okay, this is really odd. Why are the access tokens generated by shinpuru invalid? xD I have no idea what's going on at this point to be honest. Maybe try to clear your browser cookies on the shinpuru page. Could be possible that the cookie can not be overwritten or read for some reason. |
|
I had tried to login with deleted cookies and with my smartphone too, but it still dont works. Now i had a new login idea because of always thinking how to fix this but idk if this would be a good idea, but i will make a suggest request for it. |
|
Solved after a few updates. |
Type
Breaking Issue
Instances
Description
Im not able to login into the webinterface, because when i try to login after a succesfull auth im stuck at the webpath "/api/auth/oauthcallback?code=" and im not logged in, in the webinterface.
(i removed the code for this report)
Steps to reproduce
Attachments
I got no errors or anything else, just only a blank site
The text was updated successfully, but these errors were encountered: