Using with Authelia?

[YouveGotMeowxy]

Issue details

Duplicate?

Have you searched the issues of this repository if your issue is already known? yes

Actual behaviour

• When using Authelia, I can't use the Android app at all. It won't connect to my Wbag server.

Expected behaviour

• I should be able to use the Wbag app. :)

The problem seems to be that the app tries to connect to the main Wbag page itself (rather than a backend, like the API or something), and with Authelia, I have the main page protected w/2 Factor, though I believe even single factor would result in the same issue, because there's no way to login to Authelia first in the wbag app.

So effectively, in the eyes of Authelia, I'm just an anonymous (not logged in) visitor trying to access the main Wbag page.

The Authelia log just shows this:

level=info method=GET msg=Access to https://wallabag.domain.com/ (method GET) is not authorized to user , responding with status code 401path=/api/verify remote_ip=10.0.0.2 time=2022-10-30T10:54:09-05:00

There seems to be no way via the Authelia config to set a rule that would normally protect the main Wbag page except for the wbag app. However, It is possible to bypass auth for the api (which I've done for the Wallabagger Chrome extension, and works perfectly).

Currently, with Authelia running, I am:

• able to protect the main wbag page perfectly
• use the Wallabagger extension perfectly
• but I'm stuck unable to use the Android Wbag app, which I normally use extremely frequently, and is the last issue I am facing until joy. :)

Is there some way to make the app use the API rather than the front end, do do all of it's work?

Steps to reproduce the issue

1. Have Authelia installed
2. Have Wallabag installed
3. Have the Wbag Android app installed
4. Try to connect to your Wbag server via the Wbag app

Environment details

Currently using the latest Wbag container, latest Authelia container, latest Android version, latest Android wbag app version.

Your experience with wallabag Android app

Have you had any luck using wallabag Android app before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

YES. Normally, I LOVE the app for saving to my server.

[di72nn]

Unfortunately, even the 2FA included in wallabag is not supported by the app. I think the app should be able to function if it was configured before 2FA was enabled or if you enter all the credentials (username, password, client id, client secret) manually in the settings.

[YouveGotMeowxy]

It seems like the app is more of an afterthought than an equal partner in the Wallabag-sphere, as it rarely gets any love from the devs.

I'd try to help with it but I know nothing about developing apps.

[di72nn]

I suppose it can be seen that way :man_shrugging: The Android app is definitely less popular than wallabag in general (and wallabag is kind of a niche product by itself). Also, there's hardly ever been overlap between people doing Android development here and web/PHP development on the server side. So it's just the lack of developers, not priorities.

Anyway, I'm closing this issue as it is basically a duplicate of the 2FA one, but you are free to reopen this one if you need help regarding your setup.

[YouveGotMeowxy]

Honestly, I dont even use the app itself other than for it's ability to use the usual SHare icon in all my other apps, and share the URL (etc.) to my server, including the ability to tag (etc.). I do love that about that app.

Is there some other way to do that w/out the app?

[di72nn]

Same. I'm not aware of any other way to do that on Android.

[YouveGotMeowxy]

Question:

Where does the app store the Client secret, Client ID, token (etc.) that it fetches via the initial http call? Is it saved to some file?

I was thinking I could just edit that file with the token I have already created in the webui, and then it would work with Authelia.

[di72nn]

As I mentioned in the first comment, I think it may work if you simply enter username, password, client id and client secret. That can be done right in the app settings (connection settings).

The tokens are not configurable via UI (and you need root to be able to edit /data/data/fr.gaulupeau.apps.InThePoche/shared_prefs/fr.gaulupeau.apps.InThePoche_preferences.xml, with <string name="connection.api.accessToken">...</string> and <string name="connection.api.refreshToken">...</string> being the values you're interested in).

[YouveGotMeowxy]

As I mentioned in the first comment, I think it may work if you simply enter username, password, client id and client secret. That can be done right in the app settings (connection settings).

I tried, it doesn't work. This is the log in Authelia:

Access to https://wallabag.domain.com/ (method GET) is not authorized to user , responding with status code 401path=/api/verify

Unfortunately, I no longer root my phone these days, so can't access that folder/file to manually edit it.

Just curious, why is the Chrome extension able to work with Authelia:

But the Android app can't? I'm not an android dev so I can't compare the code, but can't someone who is just compare how the Chrome extension does it and add it to the Android app?

[di72nn]

https://github.com/wallabag/android-app/issues/359#issuecomment-477942215

[YouveGotMeowxy]

Thanks, I've read that before though and it doesn't address my question; that is a workaround, and if the Authelia 2Fa ever expires one has to manually go back, edit a .conf file to disable authelia, go back to the phone app, do the login, then go back to the computer, edit the .conf file again to re-enable authelia, restarting the entire SWAG server hosting all other containers in between each edit of the .conf.

My original question is, the source is right there to study for the Chrome extension; why can't the current implantation in the android app be scrapped and replaced with the same method?

Not trying to be a PITA here, I'm asking legitimate user feedback. Truly, if I had the ability I'd try to do it myself, but I don't so I have to ask those that do.

[di72nn]

I was meaning to refer to this part:

Implementing 2FA support would require to further complicate the first part. The problem is that the app shouldn't be doing that part at all: there should be a different way of getting API credentials. So implementing 2FA at this point would be like creating a crutch for a crutch.

2FA probably can be implemented without auth improvements on the server side, but it would likely require quite a few changes in the app. 2FA support was not a priority (since at least some kind of a workaround exists) and there's no one to do this work at the moment anyway :man_shrugging:

[YouveGotMeowxy]

but it would likely require quite a few changes in the app ... and there's no one to do this work at the moment

ok, so there's my real answer; no one is interested in doing it. :)