Safari not permitting auth related calls, and an unrelated question

[GrumpyOldGandalf]

Running CSL on Mac OS X 15.6.1.

When clicking "Register" or "Login" in the respective auth related pages, Safari gives a "403 (Forbidden)" error and the calls never reach the server.

Chrome does not seem to have the same problem. I am able to dev and test on Chrome without issue.

How should I go about troubleshooting this?

Also - completely separate question since I"m not sure where else to post this - when calling (reset), bb css-watch task is called after the server starts to set a watch for CSS builds when code is changed. Where is that call coming from in the code? And I would like to understand how tailwindcss works here - is it parsing the *.clj files directly to know what classes are used (and thus should be used in the output.css file), or what?

[abogoyavlensky]

@GrumpyOldGandalf Hi! Thanks a lot for reporting the issue!

How should I go about troubleshooting this?

Not sure yet, I've reproduced the issue on Desktop Safari, and suspect it somehow relates to CSRF-token and cookies management in Safari. I will try to figure out the problem and fix the issue. Looks, like the same behavior is in the Firefox.

when calling (reset), bb css-watch task is called after the server starts to set a watch for CSS builds when code is changed. Where is that call coming from in the code?

I've described the CSS dev setup in the doc at Frontend/TailwindCSS setup section. Let me know please if anything unclear.

Answering the question, bb css-watch shell call coming from the :integrant-extras.process/process it is defined in the resources/config.dev.edn in the app, and refers to the process integrant component from integrant-extras library. So specifically this call is made in that process component on the start.

fyi The resources/config.dev.edn config file is used in the dev/user.clj#reset function when the dev integrant system is restarted. It contains basic resources/config.edn and additionally the process component to start bb css-watch automatically. So, if you want, you can use resources/config.edn in the reset function and start bb css-watch manually in the separate terminal.

And I would like to understand how tailwindcss works here - is it parsing the *.clj files directly to know what classes are used (and thus should be used in the output.css file), or what?

Yes, exactly. Tailwindcss cli tool parses all files in the src directory as just plain text, find classes and build output.css based only on found classes. It is described in the resources/public/css/input.css where all settings for Tailwindcss v4 lives. Official Tailwindcss doc on this topic can be found here.

[GrumpyOldGandalf]

Thanks! I am glad you were able to reproduce the "403-Forbidden" issue and are looking into it.

Regarding the CSS watch process - ok, now I grok what's going on - thanks for explaining it!

I ended up turning css-watch "off," so to speak, to switch to Bulma for the prototype I'm working on, as I had layouts that simply weren't working, and my only theory was that somehow the css wasn't getting processed properly by tailwindcss. For example, I tried both daisyUI and plain ol' navbars, and they didn't render properly at all - it looked like a mess, in both Safari and Chrome, and I wasn't getting any errors or feedback from the regeneration. I want to return to tailwindcss at some point, so at least now I know how to turn it back on when I have time to go down that rabbit hole again.

One thing I discovered switching to Bulma is that I had to add it to fetch-assets so it was pre-saved the public/css directory, or for some reason the browser simply didn't call it/pull it down via the CDN link. It vexed me quite a bit trying to use the CDN link directly in the HTML, and not seeing it have any effect in the code. I surmised it has to do with a security feature of the framework to prevent such calls. But I'd like some understanding why the browser couldn't simply work out of the box with the CDN link. When I saved the same HTML in a local file and opened it, it worked fine. Running in the context of the server, it didn't.

Anyway. I look forward to your sleuthing on the "403-Forbidden" issue in Safari and Firefox, and any insights you can add about CSS rendering in and out of the CSL server context!

[GrumpyOldGandalf]

Actually this is a question. I have the following links in my head element in the base page:

    [:link {:rel "stylesheet"
            :href (manifest/asset "css/bulma.min.css")}]
    [:link {:type "stylesheet"
            :href (manifest/asset "css/site.css")}]

The latter just adds a class style for .gradient-text that I use in various places.

The links are rendered in the HTML, and I can click on site.css link in the source view, and it renders as text in a new pop-up tab.

However, when loading the page, only the bulma.min.css is loaded according to the network tab of the developer tools. The gradient-text class i defined in site.css has no effect.

Why? (And it works this way in both Safari and Chrome.)

[abogoyavlensky]

I wasn't getting any errors or feedback from the regeneration.

If you want to see output for each css rebuild as part of the system, you can add :opts {:err :inherit} to the process config at resources/config.dev.edn:

#merge [#include "config.edn"
        {:integrant-extras.process/process {:cmd ["bb" "css-watch"]
                                            :opts {:err :inherit}}}]

Or just disable this process component and run bb css-watch in the separate terminal manually.

I discovered switching to Bulma is that I had to add it to fetch-assets so it was pre-saved the public/css directory, or for some reason the browser simply didn't call it/pull it down via the CDN link.

Sorry, for the confusion, maybe it is not clear from the docs (Static assets management), so I will try to clarify it. Asset management is completely dead simple and unrelated to CDN or anything else. There is no build step, the way to add a new asset is described in the docs (link). There are only two steps to include a new asset:

I. Add asset to the fetch-assets bb command config and run bb fetch-assets just once to fetch a new asset to the resources/public dir:

{:url "https://cdn.jsdelivr.net/npm/bulma@1.0.4/css/bulma.min.css"
 :filepath "css/bulma.min.css"}

It might look like:

bb.edn

fetch-assets {:doc "Fetch static file assets from URLs"
              :requires ([manifest-edn.core :as manifest])
              :task (manifest/fetch-assets!
                      [{:url "https://unpkg.com/htmx.org@2.0.4/dist/htmx.min.js"
                        :filepath "js/htmx.min.js"}
                       {:url "https://cdn.jsdelivr.net/npm/alpinejs@3.14.8/dist/cdn.min.js"
                        :filepath "js/alpinejs.min.js"}
                       {:url "https://cdn.jsdelivr.net/npm/bulma@1.0.4/css/bulma.min.css"
                        :filepath "css/bulma.min.css"}])}

Note: Basically, you can do it manully, just download the bulma css-file and put it to the resources/public/css.

II. Then you need to include the new asset to the HTML body. This is regular step for any static asset in any web app.
In the src/myproject/views.clj#base function (base HTML hiccup component), please, replace:

[:link {:type "text/css"
        :href (manifest/asset "css/output.css")
        :rel "stylesheet"}]

to one with bulma:

[:link {:type "text/css"
        :href (manifest/asset "bulma.min.css")
        :rel "stylesheet"}]

Run the repl bb clj-repl and execute (reset).

Now, you will be able to use any bulma css classes in your hiccup components. For example, component button can look like:

(defn button
  [{:keys [url text props]}]
  [:a (merge {:class ["button"]
              :href url}
             props)
   text])

When I saved the same HTML in a local file and opened it, it worked fine. Running in the context of the server, it didn't.

This is weird. I will try to look into it. There should not be any differences between plain HTML file and server.

---

Apologies for the detailed explanation, I believe, you probably already nailed most of the parts, but anyway, I keep it here as a addition to the docs.

However, when loading the page, only the bulma.min.css is loaded according to the network tab of the developer tools. The gradient-text class i defined in site.css has no effect.

Why? (And it works this way in both Safari and Chrome.)

Might need to restart the app with (reset) or maybe even the repl itself. I reproduced your case on my local project that was created from scratch using Clojure Stack Lite, and all works fine. I think I publish it here in case you find it useful. (Ignore the project's name, it just random one, for demonstration):

• fetch-assets
• Include css file to HTML
• use custom class

Please, feel free to drop a message if anything unclear.

[abogoyavlensky]

btw, you could generate a project with daisyUI support built-in using :daisyui true option:

clojure -Tnew create :template io.github.abogoyavlensky/clojure-stack-lite :name myproject :daisyui true

[abogoyavlensky]

@GrumpyOldGandalf Hi! I've found the problem, it's a [ring-session/wrap-session {:cookie-attrs {:secure true}}] works a little bit different in Safari and requires HTTPS to be able to set cookies from the server. So you could make it false for dev and tests envs, and true for prod. An example of the setup with the config you could find int the commit.

fyi I'll update the config in the template as well in the context of this issue.

[GrumpyOldGandalf]

Yep, that solved it!

Thanks for figuring that out!

[abogoyavlensky]

Resolved in #17