<div dir="ltr">At the risk of oversimplifying... It reads to me like you only want to read the cookies?  (It wasn't clear to me how you planned to set them.)  Cookies are in the request:<br><br>#set ($cookies = $request.getCookies())<br><br><div><div>From there, you can grab the cookie you're looking for and act on it.</div><div><br></div><div>Greg</div><div><br></div><div> <br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 10:55 AM, Karla Borecky <span dir="ltr"><<a href="mailto:kborecky@smith.edu" target="_blank">kborecky@smith.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you, Scott. That sounds like the way to go! I figured there must be something reading cookies built into the code, since that's an important component, but I didn't think I could use it. (And, no, I really really don't want to go off the standard-install-IdP grid.) It's very probably over my head. O_o  But, have Test IdP, will travel.<div><div><div><br></div><div>Basically, I'm afraid if I have the cookie name visible - say, in javascript - then the <very rude word>s who have already screen grabbed my login image to try to trap people will be able to see the cookie name for the personal image, and display THAT, too, making their trap look even more authentic. I HATE THEM. Just saying.</div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 1:13 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I would potentially like to be able to access cookie values in my login.vm, and<br>
> it looks like the CookieTool (org.apache.velocity.tools.vie<wbr>w.tools.CookieTool)<br>
> would be the easiest way to do this.<br>
<br>
</span>I don't know anything about the toolbox stuff at all, I'm afraid. My advice for general reasons of portability is to avoid it for things you can do other ways.<br>
<span><br>
> In the end, what I'm looking into doing is display a personalized image and<br>
> phrase for the user based on cookie values - but I don't want the cookie<br>
> names to be visible (as it would be if you used javascript to do this.)<br>
<br>
</span>Leaving aside the "how", I'm not sure why that matters. The name is not secret to the user if that's what you're thinking.<br>
<br>
In terms of "how", we have a class called CookieManager that we use in the IdP and I've used it for this kind of thing in my views. There's a bean for managing per-session cookies and one for persistent cookies, and usually my use cases fit one of the two well enough that I don't need my own.<br>
<br>
The custom object support in our views means you can inject a reference to shibboleth.PersistentCookieMan<wbr>ager and use it.<br>
<span class="m_497935938404274615HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.n<wbr>et</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div class="m_497935938404274615gmail_signature" data-smartmail="gmail_signature"><div style="margin-left:40px">Karla Borecky<br>Systems Administrator<br>ITS<br>Smith College<br>Northampton, MA 01063<br></div></div>
</span></div>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br></blockquote></div><br></div>