Google Bot – removal of jsessionid – possible?

Splash Forums PrettyFaces Users Google Bot – removal of jsessionid – possible?

This topic contains 13 replies, has 6 voices, and was last updated by  domdorn 6 years, 3 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #17958

    davewilliamson
    Participant

    Hi,

    We are using Pretty Url in our app to rewrite the awful, but required, JSF url’s.

    We’re using Spring on GAE, and must say that Pretty Url is absolutely fantastic!

    We do have one problem though, that we cannot see how to config Pretty Url to do the following that we could do with urlRewriter:

    <br />
    <outbound-rule encodefirst="true"><br />
    <condition name="user-agent">googlebot.*</condition><br />
    <from>^(.*);jsessionid=.*(?.*)$</from><br />
    <to>$1$2</to><br />
    </outbound-rule><br />

    The code above, allows us to remove the jsession variable (on any, and every, page) that is created because googlebot is a cookieless environment.

    Is it possible to do this with PrettyUrl?

    Sorry if this is a newbie question, but we are newbies to PrettyUrl.

    Thanks in advance for any help

    Regards

    Dave

    #21033

    I think something like this is currently not possible with PrettyFaces. We don’t support extensive rewriting support for outbound URLs (beside the transparent rewriting of JSF URLs). Our rewriting engine currently focuses on inbound requests only as this is the part most people are interested in.

    However you may have a look at this thread for some additional information on jsessionid handling:

    http://ocpsoft.com/support/topic/url-rewrite-removing-the-jsessionid-from-the-url

    #21034

    Actually this should be possible using the <rewrite> tag: http://ocpsoft.com/docs/prettyfaces/snapshot/en-US/html_single/#inbound_rewriting.options

    <rewrite inbound="false" outbound="true" match="(?i)^(.*);jsessionid=w+(.*)" substitute="$1$2" />

    That *should* do it, but you’ll have to try it to see… if it doesn’t we should figure out why not.

    #21035

    Oh great! Why didn’t I know about the outbound flag? Must have missed that. :)

    The only thing that is still missing is the restriction to a specific user-agent. Perhaps we can implement matching against headers in the future. Perhaps during the header rewriting stuff we talked about.

    #21036

    davewilliamson
    Participant

    Thank you SO much!

    I’ll give this a go, and let you know the results!

    Unfortunately, We’re dealing with a much worse problem at the moment, and a live date is looming, so this may detract from testing this.

    I will raise a separate post for our current issue – Multiple Session Creation.

    But again, thanks for this.

    Regards

    Dave

    #21037

    Zhomart
    Participant

    I heard, GoogleBot and all major search engines treat right jsessionid.

    jsessionid is a part of the servlet specification, it’s there to maintain session ID for browsers that do not support cookies. So eliminating it, violates specification.

    And that multiple session creation unlikely but may be caused by rewriting jsessionid’s.

    #21038

    The specification also provides methods of removing the jsessinid. This is a completely normal thing to do :)

    #21039

    Did it work?

    I have now the same problem that google list with appending jsessionid and I want to remove it properly without fails so can u provide the full rewrite?

    #21040

    No one else with this problem?

    I get in all google links except the start page and appending jsessionid :(

    #21041

    domdorn
    Participant
    #21042

    Mhmm… I think complete disable of jsessionid sounds nice. I think its a security risk too. I’ll try it later. Thanks for the tip :)

    #21043

    domdorn
    Participant

    yes, its a security risk.. just google for session hijacking

    #21044

    <session-config>

    <session-timeout>${session.timeout}</session-timeout>

    <tracking-mode>COOKIE</tracking-mode>

    </session-config>

    should be fine in web.xml, or?

    #21045

    domdorn
    Participant

    if you replace ${session.timeout} with a concrete value (3600 e.g.), yes, it should do it.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

Comments are closed.