These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
K3.2.2 installation
  • I am installing K3.2.2 from scratch following http://kohanaframework.org/3.2/guide/kohana/install

    When I remove install.php I get the following error:

    Kohana_Exception [ 0 ]: A valid cookie salt is required. Please set Cookie::$salt.
    SYSPATH/classes/kohana/cookie.php [ 152 ]
    

    If I add Cookie::$salt = 'salt salt salt'; to my bootstrap file, I get the "hello, world!"

    Is there a reason I need to set a cookie salt if I am not using cookies? If there is, the install documentation should be updated.

  • If you use sessions, you use cookies.

  • But I am not using sessions (unless welcome.php does under the covers somewhere). It was a straight up, out-of-the-box install.

    I know enough to set my cookie salt in bootstrap.php, but someone new to Kohana may get frustrated that "hello, world!" does not work even if they are following the install documentation.

  • So we can't look at our local userguide to find out how to set Cookie::$salt until we have, erm, set Cookie::$salt?

  • I'm fairly sure that the default welcome doesn't use any sessions or cookies. Can you post the stack trace for the error?

  • @zombor: not sure how to post the whole thing....I'll list the highlights.

    Note that this is NOT from the install procedure, but from updating my index.php and moving my app files into the 3.2.2 application directory.

    Obviously index.php calls Request::factory()

    request.php line 202 calls Cookie::get()

    cookie.php line 67 calls Cookie::salt()

    cookie.php salt() then throws the exception (posted by ejg above) on line 152

  • Ah, so you have cookies for your domain already set. That would explain it :)

    I wouldn't really consider this a "fresh" install.

  • Would Kohana's devs ever update install.php to handle this quirk? ie; display a warning or instructions.
    Though I guess clearing your browser's Cookies (for dev/localhost etc) does actually constitute "fresh!"

  • @zombor: well, it didn't explain it for me. I ran into an exception I'd never seen before, although I upgraded in the same way that I have before.

    ejg's is a fresh installation, and he got the same problem. A fresh installation should always be clean, unless the user has ignored any of the instructions.

    This clearly needs a remedy, at the very least nickg's suggestion.

  • I ran into an exception I'd never seen before, although I upgraded in the same way that I have before.

    This functionality has been in the core for a year now.

    A fresh installation should always be clean

    We can't control any external things like cookies. This is not a "fresh" install from a complete system perspective, as there were leftover cookies from something else.

    This clearly needs a remedy, at the very least nickg's suggestion.

    This would be the only suggestion worth considering (even though there's a large number of users who never even bother with install.php), although I'm not sure what the big deal is. Just set your cookie salt and move on. It takes 2 seconds to do it.

  • Perhaps that loop should not be run if there is no cookie salt.

  • The stack trace is below. You can see it in action here: http://ejgejg.com/k3/

    It was a new directory. I uploaded Kohana. Changed the timezone and base_url in the bootstrap. Set cache and logs to writable. Went to ejgejg.com/k3/. Everything was green. Removed install.php. Went to ejgejg.com/k3 and got the error.

    Kohana_Exception [ 0 ]: A valid cookie salt is required. Please set Cookie::$salt.
    SYSPATH/classes/kohana/cookie.php [ 152 ]
    147     public static function salt($name, $value)
    148     {
    149         // Require a valid salt
    150         if ( ! Cookie::$salt)
    151         {
    152             throw new Kohana_Exception('A valid cookie salt is required. Please set Cookie::$salt.');
    153         }
    154 
    155         // Determine the user agent
    156         $agent = isset($_SERVER['HTTP_USER_AGENT']) ? strtolower($_SERVER['HTTP_USER_AGENT']) : 'unknown';
    157 
    SYSPATH/classes/kohana/cookie.php [ 67 ] » Kohana_Cookie::salt(arguments)
    SYSPATH/classes/kohana/request.php [ 202 ] » Kohana_Cookie::get(arguments)
    DOCROOT/index.php [ 108 ] » Kohana_Request::factory()
    
  • ejg's was a fresh installation. I don't know what "...from a complete system perspective" has got to do with it. Running the install procedure should not throw an exception, especially one which says "Please set Cookie::$salt." without mentioning how or where. Your "large number of users who never even bother with install.php" can presumably look after themselves. The point of an install procedure is that it enables newcomers to get started. That's "the big deal". "It only takes 2 seconds to do it" if you already know how.

  • ejg's was a fresh installation. I don't know what "...from a complete system perspective" has got to do with it

    Because there were cookies left over for her domain. The system cleans the cookies on every page load, so if there's no cookie salt set, it will fail.

    Running the install procedure should not throw an exception

    There is no "running the install procedure". install.php is poorly named. Kohana is not a "unzip it and run your application" type of framework.

    without mentioning how or where

    Right, because reading the documentation would be asking too much.

    Again, I'd be willing to discuss changing install.php to check for this, but anything beyond that is just silly.

  • There is no "running the install procedure".

    Whatever you call it, it's supposed to install the framework. Throwing an exception is not acceptable.

    because reading the documentation would be asking too much.

    So throw an exception and have the user try to figure out the problem from the online docs? How very Kohana.

    Having established that Cookie::$salt is not set, your install procedure should handle it gracefully.

  • it's supposed to install the framework.

    What's supposed to install the framework? Installing the framework consists of copying or cloning the files. That's it. install.php does not install anything. All it does it run some system checks. Like I said, it's poorly named. Could it also check to make sure your domain's cookie array is empty? Sure. However, there's no "handling" Cookie::$salt not being there that can go on. The "handling" of it IS the exception being thrown!

    have the user try to figure out the problem from the online docs?

    It tells you EXACTLY what to do: Please set Cookie::$salt. This stuff isn't rocket science. You are making a mountain out of a mole hill.

  • You are splitting hairs about terminology. I know perfectly what your install does. The fact is, you have a procedure called "install" which throws an exception when it could be handling the missing $salt gracefully.

    It tells you EXACTLY what to do: Please set Cookie::$salt.

    How? Where? We have different concepts of "exactly". As for making a mountain out of a molehill, you could have fixed this in far fewer words than you have expended in denial.

    Kafka would have been at home here.

    " I installed..."

    "No you didn't. Install is poorly named. It doesn't install anything"

    "Well, anyway, I got an exception which I didn't understand".

    "Well you should have understood it. It isn't rocket science."

    How very Kohana.

  • The only "install procedure" we have is here: http://kohanaframework.org/3.2/guide/kohana/install

    The fact is, you have a procedure called "install" which throws an exception when it could be handling the missing $salt gracefully.

    The whole point of the check is that is does not handle it gracefully. We throw that exception for a very specific reason. We cannot just ignore it and pretend it didn't happen.

    And again (for the third time), I am more than willing to discuss the merits of adding a check to the install.php file to make sure your cookies are gone. This is the only acceptable solution that I can seen suggested here. You have not even made any suggestions.

    And terminology is very important. When we use the wrong words, we don't make a clear point. That's why the install.php file should be called anything but.

  • Also:

    How very Kohana.

    How very Kohana.

    Stop being disrespectful.

  • Maybe call it installed.php

    As it does other checks without throwing exceptions (PHP ver, extensiosn loaded, Determine URI)
    +1 for checking for stale cookies.

    If I write and deploy a simple app, that does not use Cookies, to an existing domain; it is entirely possiple a client browesr will have "stale" cookies and throw that exception. Of course if I've set a cookie::$salt it's OK.

    So really setting cookie::$salt is the install procedure - you just have to code it manually.
    Possibly Kohana (install.php) could generate one for you, to a config file, but that's not very Kohana :)

  • I think it should be called system_check.php

    it is entirely possiple a client browesr will have "stale" cookies and throw that exception.

    This won't tell you about stale cookies on remote systems ;)

  • Stop being disrespectful.

    Don't be silly. "How very Kohana" is an opinion based on several years of using Kohana and visiting this forum. If you want to see real disrespect, go looking for all the badmouthing Kohana gets across the Internet.

    You have not even made any suggestions.

    I suggested that it is not good practice to have install.php throw an exception in circumstances which the developer could foresee but the newcomer could not.

    But if you must throw an exception, your exception could at least be more specific about how and where to set $salt. Alternatively set a default in bootstrap.php and have install.php warn the user to change it. Or just have install.php note the absence of $salt and warn the user at the end of its process.

  • Here's a suggestion... why not remove the install.php check from index.php once you verified that everything is set up correctly?

  • I suggested that it is not good practice to have install.php throw an exception in circumstances which the developer could foresee but the newcomer could not.

    install.php does not even throw this exception. Also, this is not a suggestion on an actual solution to this "problem".

    Alternatively set a default in bootstrap.php and have install.php warn the user to change it. Or just have install.php note the absence of $salt and warn the user at the end of its process.

    This is impossible, as bootstrapping doesn't run.

  • But if you must throw an exception, your exception could at least be more specific about how and where to set $salt. Alternatively set a default in bootstrap.php and have install.php warn the user to change it. Or just have install.php note the absence of $salt and warn the user at the end of its process.

    I guess I agree it's not 100% clear "how and where to set $salt" but in some ways that's because there are any number of options. Maybe it could be improved (@ejg is right that it's not mentioned on http://kohanaframework.org/3.2/guide/kohana/install - I'm sure they'd welcome a ticket and pull request for an edit to clarify those docs, for example), but I don't see that the current message would be a major blocker to any developer installing. Wouldn't most people assume that if you need to set a static property of a class you'd probably do it in your bootstrap unless you'd a reason to do it elsewhere?

    However, the latter part of your suggestion is a really bad idea. The whole point of this is to make it impossible for people to deploy this out of the box and use cookies without using a unique, secret, salt for the signatures. If the user doesn't notice that this needs to be done (because it just uses a default till told otherwise, or because the warning isn't unpleasant enough to be noticed) then they risk significant security issues on their site.

    Far too many frameworks and applications allow an inexperienced user to deploy them "insecure by default". As a developer, I'd much rather hit fatal errors than be allowed to continue oblivious to the fact I haven't configured an important security config until my customers experience some sort of breach as a result.

  • install.php does not even throw this exception.

    More pedantry. You know perfectly well what I mean.

    For the sake of clarity, this is where we are:

    1. Newcomer runs install.php;

    2. an exception is thrown in circumstances which the developer could foresee but the newcomer could not;

    3. the developer doesn't care.

    @andrewc: They look like sensible points; but you seem to expect that the newcomer is what you call a "developer" - a term whose meaning is imprecise, to me at least - and/or has already looked through all the underlying code. I maintain that anyone should be able to get to the starting line without having to endure a thread such as this.

  • @tangerine

    I maintain that anyone should be able to get to the starting line without having to endure a thread such as this.

    No it shouldn't. I wouldn't fix your car, because I'm not a mechanic and you wouldn't bring your car to me, because you know I'm not a mechanic...

    Kohana is not for everyone, so as any other framework or PHP or programming as a matter of fact. You could be a programmer, but then you probably wouldn't start with PHP and you could use a PHP framework, but then again you would proabably learn PHP first...

  • There's a difference between a developer new to the framework, where they might not be otherwise aware of the cookie salt and therefore might miss setting it - they will have absolutely zero problem with the way it works just now.

    Then there's people so new to coding they don't know how to set a static property and guess that the bootstrap is a sensible place to do so. Sure, they'll struggle as it is now. But guess what, if you disable this they'll get lots of lovely green ticks, and an app that can say hello world. And then they'll be just as stuck.

    Like it or not, Kohana isn't designed for the latter. If you're prepared to put the effort in its actually a great framework to learn good programming practices. But you have to do it (and learn how to do it) yourself.

  • @feketegy: Your analogy is meaningless. I wouldn't fix my car either, but I use Kohana.

    @andrewc: "And then they'll be just as stuck." Wrong. They will be able to use the documentation to get started. Speaking of documentation, I suppose there would be no point asking why there is no mention of setting $salt in the "Installation" section of the docs?

    Whoever Kohana may or may not be "designed for", it should not be throwing an exception before we've even got started.

  • @tangerine

    Whoever Kohana may or may not be "designed for", it should not be throwing an exception before we've even got started.

    And why is that? Everybody on this forum doesn't seem to have a problem with it, it's only you who has it. As how @andrewc wrote above, Kohana is not for everybody, there are hundreds of other PHP frameworks that may suit your coding style better.

    Also, on documentation you're more than welcome to contribute to it with tutorials, patches, etc. I fought for this too, but I realized that it's better for me (and for others who use Kohana) to actually read the source code and the API browser here: http://kohanaframework.org/3.2/guide/api you understand the whole workings much better than by going through the steps in a tutorial.

  • @tangerine - there's every point in asking why $salt isn't mentioned in the install guide - in fact if you look up the thread I suggested that one of you could make a ticket and pull request to add it. I expect that documentation is missing because it was overlooked in a version upgrade - the $salt exception was introduced in 3.1 or 3.2 (I don't recall).

    As with all these "Kohana's too hard to get started with, there's information missing from the docs" it would be so much more productive for the people who have complaints to just suggest or better contribute improvements to the docs rather than get into big arguments about changing deliberate design decisions in the implementation that have been taken for good reasons.

    However, I genuinely disagree that someone who can't resolve this on their own will be able to do anything useful with the framework even if they can get to the docs, which are limited to the structure of the Kohana framework, the API and so on and assume a basic developer knowledge and initiative.

  • I expect that documentation is missing because it was overlooked in a version upgrade - the $salt exception was introduced in 3.1 or 3.2 (I don't recall).

    We mentioned it in the 3.1 migration guide here: http://kohanaframework.org/3.1/guide/kohana/upgrading#cookie-salts

    I agree it should be in the install guide in the docs though. It was overlooked.

  • Kohana newbie here, (but PHP 'not-newbie'). Installed Kohana on minty fresh, spanking new VPS in advance of moving the domain. So it shouldn't have any cookies - and yet I got the Unsalted Cookie error. I was able to make it go away, but then got a different installation error

    throw new HTTP_Exception_404('The requested URL :uri was not found on this server.', 88 array(':uri' => $request->uri()));

    I specifically asked the hosting company about Kohana compatibility before I signed up the VPS and the test page gave me a pass, but I also saw a note about the 'http Request' class possibly not working completely. It was a little ambiguous. I got the green "PASSED" notice, then the unsalted cookie and then this HTTP error.

    My search for installation help brought me here. I am happy to consult the manual before asking for help, because Kohana looks like an awesome framework. I just wanted to share my experience so far.

    BTW: I am installing Kohana off the root because I don't know if it makes a difference. I would hope not, but I can't be sure.

  • It has nothing to do with your server, it has to do with your local browser storing the cookies.

    As for the other error, it looks like you are just getting a normal 404 error page. With the limited details you've given it's impossible to say why.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion